Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Christoph Lameter
On Mon, 23 Jul 2007, Andrew Morton wrote: > So this: > > /* >* Be lazy and only check for valid flags here, keeping it out of the >* critical path in kmem_cache_alloc(). >*/ > BUG_ON(flags & ~(GFP_DMA | __GFP_ZERO | GFP_LEVEL_MASK)); > > would no longer need

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Andrew Morton
On Mon, 23 Jul 2007 15:41:36 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Mon, 23 Jul 2007, Andrew Morton wrote: > > > > OK, well that was weird. So > > > > kmalloc(42, GFP_KERNEL|__GFP_ZERO); > > > > duplicates > > > > kzalloc(42, GFP_KERNEL); > > > > Why do it b

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Christoph Lameter
On Mon, 23 Jul 2007, Andrew Morton wrote: > On Mon, 23 Jul 2007 14:43:23 -0700 > Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > __GFP_ZERO is implemented by the slab allocators (the page allocator > > has no knowledge about the length of the object to be zeroed). The slab > > allocators do n

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Linus Torvalds
On Mon, 23 Jul 2007, Andrew Morton wrote: > > OK, well that was weird. So > > kmalloc(42, GFP_KERNEL|__GFP_ZERO); > > duplicates > > kzalloc(42, GFP_KERNEL); > > Why do it both ways? Both ways? The latter *is* the former. That's how kzalloc() is implemented these days. Andrew

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Andrew Morton
On Mon, 23 Jul 2007 14:43:23 -0700 Christoph Lameter <[EMAIL PROTECTED]> wrote: > __GFP_ZERO is implemented by the slab allocators (the page allocator > has no knowledge about the length of the object to be zeroed). The slab > allocators do not pass __GFP_ZERO to the page allocator. OK, well that

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Christoph Lameter
__GFP_ZERO is implemented by the slab allocators (the page allocator has no knowledge about the length of the object to be zeroed). The slab allocators do not pass __GFP_ZERO to the page allocator. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Peter Zijlstra
On Mon, 2007-07-23 at 11:37 -0700, Andrew Morton wrote: > On Mon, 23 Jul 2007 12:03:40 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > Daniel recently spotted that __GFP_ZERO is not (and has never been) > > part of GFP_LEVEL_MASK. I could not find a reason for this in the > > original patch:

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Andrew Morton
On Mon, 23 Jul 2007 12:03:40 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote: > Daniel recently spotted that __GFP_ZERO is not (and has never been) > part of GFP_LEVEL_MASK. I could not find a reason for this in the > original patch: 3977971c7f09ce08ed1b8d7a67b2098eb732e4cd in the -bk > tree. It d

Re: [PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Mel Gorman
On (23/07/07 12:03), Peter Zijlstra didst pronounce: > > Daniel recently spotted that __GFP_ZERO is not (and has never been) > part of GFP_LEVEL_MASK. I could not find a reason for this in the > original patch: 3977971c7f09ce08ed1b8d7a67b2098eb732e4cd in the -bk > tree. > > This of course is in s

[PATCH] add __GFP_ZERP to GFP_LEVEL_MASK

2007-07-23 Thread Peter Zijlstra
Daniel recently spotted that __GFP_ZERO is not (and has never been) part of GFP_LEVEL_MASK. I could not find a reason for this in the original patch: 3977971c7f09ce08ed1b8d7a67b2098eb732e4cd in the -bk tree. This of course is in stark contradiction with the comment accompanying GFP_LEVEL_MASK. S