twitter: linux.kernel - 26 new messages in 20 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* kernel-shark: fix unitialized handle compile warnings - 3 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/2ae6ffbd06a5c48a?hl=en
* trace-cmd: teach git to ignore dependency files (*.d) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/76b5b681a1deab29?hl=en
* Improving OOM killer - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
* sky2: receive dma mapping error handling - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/03d63adef2419307?hl=en
* improve sys_personality for compat architectures - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/c11a869d434f48b8?hl=en
* bitops: compile time optimization for hweight_long(CONSTANT) - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
* ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC: early
exception 08 rip 246:10 error ffffffff810251b5 cr2 0) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/42f60222e13dd142?hl=en
* linux-next: manual merge of the omap_dss2 tree with the omap tree - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/6301abd44550ec77?hl=en
* hrtimer, softirq: Fix hrtimer->softirq trampoline - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cc29c778ec3f3352?hl=en
* slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/90562c9ef16cf2a0?hl=en
* ssb: Fix CONFIG_SSB_SDIOHOST typo - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/66b3018f2aa264bc?hl=en
* drivers/ata: Fix continuation line formats - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d822eba66af5e806?hl=en
* "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to
hang - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/24244e271ec4cffc?hl=en
* Input: wacom - Convert remaining ids, part two - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/180a14dbdf464341?hl=en
* perf report for .ko files - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f73df95337ab2b2b?hl=en
* alpha: PTR_ERR overwrites -EINVAL in syscall osf_mount - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/16fdd0b211d48292?hl=en
* perf tools: using O_LARGEFILE to open perf data file - fix - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/5e0297b0b8d16155?hl=en
* name_count maxed, losing inode data: dev=00:05, inode=5221 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fa648e2374d7d967?hl=en
* x86: fix race in create_irq_nr on irq_desc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8d79051b75e0b2aa?hl=en
* Merge of the enhanced reimplemention of the kfifo API - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bb90a5c606a34ba3?hl=en

==============================================================================
TOPIC: kernel-shark: fix unitialized handle compile warnings
http://groups.google.com/group/linux.kernel/t/2ae6ffbd06a5c48a?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Feb 3 2010 9:00 am
From: Steven Rostedt

On Wed, 2010-02-03 at 17:42 +0100, John Kacur wrote:

>
> Okay, are you going to push it to your repo for us? I would offer to
> push it through mine if it would save you time, but it's probably
> quicker if you just handle it.

Yeah, I'll pull via email the one patch and then do this one by hand.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Wed, Feb 3 2010 9:20 am
From: Darren Hart

Steven Rostedt wrote:
> On Wed, 2010-02-03 at 17:07 +0100, John Kacur wrote:
>> On Mon, Feb 1, 2010 at 5:50 PM, Darren Hart <dvhltc@us.ibm.com> wrote:
>>> Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
>>> ---
>>> trace-read.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/trace-read.c b/trace-read.c
>>> index a04c85b..5befaba 100644
>>> --- a/trace-read.c
>>> +++ b/trace-read.c
>>> @@ -216,7 +216,7 @@ static void read_rest(void)
>>> r = read(input_fd, buf, BUFSIZ);
>>> if (r > 0) {
>>> buf[r] = 0;
>>> - printf(buf);
>>> + printf("%s", buf);
>>> }
>>> } while (r > 0);
>>> }
>>> --
>>> 1.6.3.3
>>>
>> Oh! Obviously correct, thanks Darren.
>
> Of the three patches, I think this is the only one that is correct ;-)

The other appear to depend on the guint arch specific implementation of
the guint64 type, so the only way to fix it with a cast to ull - or to
not use g types at all. Bleh.

--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Wed, Feb 3 2010 9:30 am
From: Steven Rostedt

On Wed, 2010-02-03 at 09:12 -0800, Darren Hart wrote:

> > Of the three patches, I think this is the only one that is correct ;-)
>
> The other appear to depend on the guint arch specific implementation of
> the guint64 type, so the only way to fix it with a cast to ull - or to
> not use g types at all. Bleh.

I'm fixing it up by typecasting it to (u64), and defining it.

I probably should never have used guint64 but since that's the "glib"
thing to do, and when in Rome do as the Romans do, even if the Romans
are doing crap!

-- Steve

==============================================================================
TOPIC: trace-cmd: teach git to ignore dependency files (*.d)
http://groups.google.com/group/linux.kernel/t/76b5b681a1deab29?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 9:10 am
From: Steven Rostedt

On Wed, 2010-02-03 at 17:51 +0100, John Kacur wrote:
> >From fc439caf5a0df5ff735d8f783a29709849c4d83b Mon Sep 17 00:00:00 2001
> From: John Kacur <jkacur@redhat.com>
> Date: Wed, 3 Feb 2010 16:39:15 +0100
> Subject: [PATCH] trace-cmd: teach git to ignore dependency files (*.d)
>
> Teach git to ignore dependency files (*.d)

Thanks, but this is already in the master branch. But it ignores ".*.d"
instead.

-- Steve

>
> Signed-off-by: John Kacur <jkacur@redhat.com>
> ---
> .gitignore | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 8e8f5a4..0dcd8cd 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -5,6 +5,7 @@ trace-cmd
> *.dat
> *.patch
> *~
> +*.d
> kernelshark
> trace-graph
> trace-view

==============================================================================
TOPIC: Improving OOM killer
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 9:10 am
From: Balbir Singh

* Rik van Riel <riel@redhat.com> [2010-02-03 09:49:18]:

> On 02/01/2010 05:02 PM, Lubos Lunak wrote:
>
> > In other words, use VmRSS for measuring memory usage instead of VmSize, and
> >remove child accumulating.
>
> I agree with removing the child accumulating code. That code can
> do a lot of harm with databases like postgresql, or cause the
> system's main service (eg. httpd) to be killed when a broken cgi
> script used up too much memory.
>
> IIRC the child accumulating code was introduced to deal with
> malicious code (fork bombs), but it makes things worse for the
> (much more common) situation of a system without malicious
> code simply running out of memory due to being very busy.
>

For fork bombs, we could do a number of children number test and have
a threshold before we consider a process and its children for
badness().

> I have no strong opinion on using RSS vs VmSize.
>

David commented and feels strongly about RSS and prefers VmSize.

--
Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: sky2: receive dma mapping error handling
http://groups.google.com/group/linux.kernel/t/03d63adef2419307?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 9:10 am
From: Michael Breuer

On 02/03/2010 11:56 AM, Stephen Hemminger wrote:
> On Wed, 03 Feb 2010 11:47:19 -0500
> Michael Breuer<mbreuer@majjas.com> wrote:
>
>
>> Tracked this down. The status being returned is 0x3c0080 - good flow
>> control packets. Nothing is actually being dropped (confirmed by packet
>> trace on switch compared with packet trace on server).
>>
>> I whipped up a trivial patch to not count these as dropped packets and
>> will post to netdev.
>>
>> I'm not really sure what the driver should be doing in this case, but
>> resubmit seems to work.
>>
> Looks like a flow control negotiation issue. You probably turned off
> flow control on the Linux side, but the switch is still doing flow
> control.
>
>
According to the driver:
Feb 3 12:03:02 mail kernel: sky2 eth0: Link is up at 1000 Mbps, full
duplex, flow control both

So if the rx flow control packet status is due to flow control being
disabled, then there's a different issue.

== 2 of 2 ==
Date: Wed, Feb 3 2010 9:20 am
From: "Justin P. Mattock"

On 02/03/10 08:56, Stephen Hemminger wrote:
> On Wed, 03 Feb 2010 11:47:19 -0500
> Michael Breuer<mbreuer@majjas.com> wrote:
>
>> Tracked this down. The status being returned is 0x3c0080 - good flow
>> control packets. Nothing is actually being dropped (confirmed by packet
>> trace on switch compared with packet trace on server).
>>
>> I whipped up a trivial patch to not count these as dropped packets and
>> will post to netdev.
>>
>> I'm not really sure what the driver should be doing in this case, but
>> resubmit seems to work.
>
> Looks like a flow control negotiation issue. You probably turned off
> flow control on the Linux side, but the switch is still doing flow
> control.
>

I noticed this in a hotel last week, I can try
at the home to see if this fires of, if so
I can test any patches you have.

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: improve sys_personality for compat architectures
http://groups.google.com/group/linux.kernel/t/c11a869d434f48b8?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 9:10 am
From: Arnd Bergmann

On Tuesday 02 February 2010 17:31:45 Christoph Hellwig wrote:
>
> On Tue, Feb 02, 2010 at 03:36:51PM +0100, Arnd Bergmann wrote:
> > > - return (long)old;
> > > + return (long)(old == PER_LINUX32 ? PER_LINUX : old);
> > > }
> >
> > What does this do for a native 64 bit process setting PER_LINUX32?
> > It looks to me like it could never set it back to the original
> > value, or am I missing something here?
> >
> > It's what the arch specific code does already, but it seems a bit
> > strange anyway.
>
> Indeed, this prevents a process from going back to 64bit. And while
> the setarch tool in util-linux also allows going back to 64-bit the
> typical use case seems to be going into 32-bit mode.

It appears that setarch can only go back into 64 bit mode on x86
because that does not wire up sys32_personality at all -- it always
uses the regular sys_personality, which allows going both ways.

Your patch changes the behavior on x86 to also make the change
to PER_LINUX32 permanent, which seems consistent but possibly not
what people want. I still wonder if anything other than setarch
actually calls personality() to set PER_LINUX32 and what the
real intention of sys32_personality is. From what I can tell here,
it may be best to kill the special handling of PER_LINUX32 entirely
and make everyone use the existing sys_personality.

> But if the consensus is that we should fix this properly I can
> replace the patch with one introducing a compat_sys_personality
> which only gets used for compat tasks.

Right now, sparc64 and powerpc64 use sys32_personality for both native
and compat tasks, x86 never uses it and all others use it only for
compat tasks. That seems more sensible if we keep this function at
all.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Wed, Feb 3 2010 9:20 am
From: David Miller

From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 3 Feb 2010 18:06:27 +0100

>> But if the consensus is that we should fix this properly I can
>> replace the patch with one introducing a compat_sys_personality
>> which only gets used for compat tasks.
>
> Right now, sparc64 and powerpc64 use sys32_personality for both native
> and compat tasks, x86 never uses it and all others use it only for
> compat tasks. That seems more sensible if we keep this function at
> all.

If it only gets used for compat tasks, you can only switch in
one direction. I think it needs to be handled for both compat
and non-compat tasks, in order to allow for that.

That's why powerpc64 and sparc64 do things the way they do,
I am pretty sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: bitops: compile time optimization for hweight_long(CONSTANT)
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 9:20 am
From: "H. Peter Anvin"

On 02/03/2010 07:47 AM, Peter Zijlstra wrote:
>
> From what I know the popcnt ins on x86 is relatively new, hpa was going
> to look at supporting it using alternatives.
>

And kernel-specific stuff like alternatives is pretty much the one thing
that gcc *can't* do for us.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

== 2 of 2 ==
Date: Wed, Feb 3 2010 9:20 am
From: "H. Peter Anvin"

On 02/03/2010 05:39 AM, Wu Fengguang wrote:
>
>> (I wonder if it could have used __builtin_popcount)
>>
>> (I wonder which gcc versions support __builtin_popcount)
>

I think 4.0 or later, but it often generates calls to libgcc, which
would mean adding libgcc functions to the kernel (which some arches
already do.)

> This is how Jamie Lokier first recommended it to me:
>
> Checked GCC 3.4.3 / 4.1 / 4.4: It expands as a compile-time
> constant if the argument is a compile-time constant, so can be
> used in BUILD_BUG_ON() and even for array sizes etc.
>
> Is there an official lowest GCC version that Linux supports?

3.4, I believe.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

==============================================================================
TOPIC: ohci1394_dma=early crash since 2.6.32 (was Re: [Bug #14487] PANIC:
early exception 08 rip 246:10 error ffffffff810251b5 cr2 0)
http://groups.google.com/group/linux.kernel/t/42f60222e13dd142?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 9:20 am
From: "Justin P. Mattock"

On 02/03/10 01:18, Jan Beulich wrote:
>>>> "Justin P. Mattock"<justinmattock@gmail.com> 03.02.10 02:43>>>
>> The only thing I can think of at this point
>> is maybe the CFLAGS I used to build this system.
>> (as for the x86_32 working and x86_64 failing not sure);
>>
>> I'm curious to see if anybody else is hitting this?
>
> I think it is pretty clear how a page fault can happen here (but you're
> observing a double fault, which I cannot explain [nor can I explain
> why the fault apparently didn't get an error code pushed, which is
> why address and error code displayed are mixed up]): I would
> suspect that FIX_OHCI1394_BASE is now in a different (virtual) 2Mb
> range than what is covered by level{1,2}_fixmap_pgt, but this was
> a latent issue even before that patch (just waiting for sufficiently
> many fixmap entries getting inserted before
> __end_of_permanent_fixed_addresses).
>
> The thing is that head_64.S uses hard-coded numbers, but doesn't
> really make sure (at build time) that the fixmap page tables established
> indeed cover all the entries of importance (and honestly I even can't
> easily tell which of the candidates - FIX_DBGP_BASE,
> FIX_EARLYCON_MEM_BASE, and FIX_OHCI1394_BASE afaict - really
> matter). If either of the first does, the only reasonable solution imo
> is to move FIX_OHCI1394_BASE out of the boot time only range into
> the permanent range (unless the other two can be moved into the
> boot time only range). And obviously the hard coded numbers
> should be eliminated from head_64.S.
>
> Jan
>
>

Thanks for your info on this. I can try today moving things
around just to see. Looking more into this(keep in mind I
have no idea how these page,fix_to_virt calls etc.. work)
I was thinking with what stefan had mentioned ___alloc_bootmem_node
(still need to look into what that function does)maybe keeping fixmap.h
as is and looking somewhere else might be where the fix might be(but
could be wrong).

In any case I'll have another go at this today.

Justin P. Mattock

==============================================================================
TOPIC: linux-next: manual merge of the omap_dss2 tree with the omap tree
http://groups.google.com/group/linux.kernel/t/6301abd44550ec77?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 9:20 am
From: Tony Lindgren

* Grazvydas Ignotas <notasas@gmail.com> [100203 04:27]:
> hi,
>
> On Wed, Feb 3, 2010 at 6:29 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Tomi,
> >
> > Today's linux-next merge of the omap_dss2 tree got a conflict in
> > arch/arm/mach-omap2/board-omap3pandora.c between commit
> > f8b6f704105164eac7c043a48f79c4234e03e4b2 ("omap: Rename hsmmc symbols to
> > reflect independence from twl4030") from the omap tree and commit
> > aacb4387a1e6f3b57977375532c6d8e47fcd5652 ("OMAP: pandora: add DSS2
> > support and related regulators") from the omap_dss2 tree.
>
> I've rebased my patch against linux-omap/for-next (attached). To fix
> the conflict, Tomi can rebase his queue on linux-omap/for-next, or
> Tony can simply take this to his queue - this has no "hard"
> dependencies on other queued DSS2 changes, has only board file changes
> and builds fine in linux-omap/for-next. I would prefer the second
> option, as I plan sending more boardfile changes to linux-omap.

Thanks Stephen and Grazvydas.

This sounds good to me, I've added this patch into omap for-next.

Tomi can you please drop the earlier version from your branch?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: hrtimer, softirq: Fix hrtimer->softirq trampoline
http://groups.google.com/group/linux.kernel/t/cc29c778ec3f3352?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 9:30 am
From: tip-bot for Peter Zijlstra

Commit-ID: b9c3032277f756e73f6c673419dc414155e04e46
Gitweb: http://git.kernel.org/tip/b9c3032277f756e73f6c673419dc414155e04e46
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
AuthorDate: Wed, 3 Feb 2010 18:08:52 +0100
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 3 Feb 2010 18:17:40 +0100

hrtimer, softirq: Fix hrtimer->softirq trampoline

hrtimers callbacks are always done from hardirq context, either the
jiffy tick interrupt or the hrtimer device interrupt.

[ there is currently one exception that can still call a hrtimer
callback from softirq, but even in that case this will still
work correctly. ]

Reported-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Yury Polyanskiy <ypolyans@princeton.edu>
Tested-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Acked-by: David S. Miller <davem@davemloft.net>
LKML-Reference: <1265120401.24455.306.camel@laptop>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
kernel/softirq.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/kernel/softirq.c b/kernel/softirq.c
index a09502e..7c1a67e 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -500,22 +500,17 @@ EXPORT_SYMBOL(tasklet_kill);
*/

/*
- * The trampoline is called when the hrtimer expires. If this is
- * called from the hrtimer interrupt then we schedule the tasklet as
- * the timer callback function expects to run in softirq context. If
- * it's called in softirq context anyway (i.e. high resolution timers
- * disabled) then the hrtimer callback is called right away.
+ * The trampoline is called when the hrtimer expires. It schedules a tasklet
+ * to run __tasklet_hrtimer_trampoline() which in turn will call the intended
+ * hrtimer callback, but from softirq context.
*/
static enum hrtimer_restart __hrtimer_tasklet_trampoline(struct hrtimer *timer)
{
struct tasklet_hrtimer *ttimer =
container_of(timer, struct tasklet_hrtimer, timer);

- if (hrtimer_is_hres_active(timer)) {
- tasklet_hi_schedule(&ttimer->tasklet);
- return HRTIMER_NORESTART;
- }
- return ttimer->function(timer);
+ tasklet_hi_schedule(&ttimer->tasklet);
+ return HRTIMER_NORESTART;
}

/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big?
http://groups.google.com/group/linux.kernel/t/90562c9ef16cf2a0?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 9:30 am
From: Richard Kennedy

On Wed, 2010-02-03 at 09:41 -0600, Christoph Lameter wrote:
> On Wed, 3 Feb 2010, Richard Kennedy wrote:
>
> > slub.c sets the default value of ARCH_SLAB_MINALIGN to sizeof(unsigned
> > long long) if the architecture didn't already override it.
> >
> > And as x86_32 doesn't set a value this means that slab objects get
> > aligned to 8 bytes, potentially wasting 4 bytes per object. Slub forces
> > objects to be aligned to sizeof(void *) anyway, but I don't see that
> > there is any need for it to be 8 on 32bits.
>
> Note that 64 bit entities may exist even under 32 bit (llong) that need
> to be aligned properly.
>
> struct buffer_head contains a sector_t which is 64 bit so you should align
> to an 8 byte boundary.
>
> > I'm working on a patch to pack more buffer_heads into each kmem_cache
> > slab page.
> > On 32 bits the structure size is 52 bytes and with the alignment applied
> > I end up with a slab of 73 x 56 byte objects. However, if the minimum
> > alignment was sizeof(void *) then I'd get 78 x 52 byte objects. So there
> > is quite a memory saving to be had in changing this.
>
> SLUB is not restricted to order 0 pages and can use order 1 or 2 pages as
> long as this reduces the memory footprint (byte wastage in a slab page is
> reduced) and as long as the kernel has contiguous memory available. It
> will use order 0 when memory is fragmented.
>
> > Can I define a ARCH_SLAB_MINALIGN in x86_64 to sizeof(void *) ?
> > or would it be ok to change the default in slub.c to sizeof(void *) ?
> >
> > Or am I missing something ?
>
> I'd say leave it alone.

I definitely don't want to break the alignment ;) but gcc aligns
unsigned long long on 4 byte boundaries on 32 bit.

Running this test code :-

#ifdef __compiler_offsetof
#define offsetof(TYPE,MEMBER) __compiler_offsetof(TYPE,MEMBER)
#else
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

twitter

Wednesday, February 3, 2010

linux.kernel - 26 new messages in 20 topics - digest

No comments:

Post a Comment