On (24/07/07 12:25), Andrew Morton didst pronounce:
> On Tue, 24 Jul 2007 12:07:51 -0700
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > Then there are some other flags. I am wondering why they are in
> > GFP_LEVEL_MASK?
> >
> > __GFP_COLD Does not make sense for slab allocators since we
On (24/07/07 12:25), Andrew Morton didst pronounce:
On Tue, 24 Jul 2007 12:07:51 -0700
Christoph Lameter [EMAIL PROTECTED] wrote:
Then there are some other flags. I am wondering why they are in
GFP_LEVEL_MASK?
__GFP_COLD Does not make sense for slab allocators since we have
On Tue, 24 Jul 2007 16:58:51 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> > __GFP_COMP I'm not so sure about.
> > drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like
> > infiniband)
> > pass it into dma_alloc_coherent()
On Tue, 24 Jul 2007, Andrew Morton wrote:
> __GFP_COMP I'm not so sure about.
> drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like infiniband)
> pass it into dma_alloc_coherent() which some architectures implement via
> slab. umm,
> arch/arm/mm/consistent.c is one such.
Should
On Tue, 24 Jul 2007 16:00:32 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> > I think I'll duck this for now. Otherwise I have a suspicion that I'll
> > be the first person to run it and I'm too old for such excitement.
>
> I always
On Tue, 24 Jul 2007, Andrew Morton wrote:
> I think I'll duck this for now. Otherwise I have a suspicion that I'll
> be the first person to run it and I'm too old for such excitement.
I always had the suspicion that you have some magical script
which will immediately tell you that a patch is
On Tue, 24 Jul 2007 12:36:59 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Jul 2007, Andrew Morton wrote:
>
> > > __GFP_MOVABLE The movability of a slab is determined by the
> > > options specified at kmem_cache_create time. If this is
> > >
On Tue, 24 Jul 2007, Andrew Morton wrote:
> > __GFP_MOVABLE The movability of a slab is determined by the
> > options specified at kmem_cache_create time. If this is
> > specified at kmalloc time then we will have some random
> > slabs movable and others
On Tue, 24 Jul 2007 12:07:51 -0700
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Then there are some other flags. I am wondering why they are in
> GFP_LEVEL_MASK?
>
> __GFP_COLDDoes not make sense for slab allocators since we have
> to touch the page immediately.
>
>
GFP_LEVEL_MASK is used to allow the pass through of page allocator
flags. Currently these are
#define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
__GFP_NOFAIL|__GFP_NORETRY|__GFP_COMP| \
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
> > There is another exception for __GFP_DMA.
>
> non of the zone specifiers are
__GFP_DMA is handled in a similar way to __GFP_ZERO though. Its explicitly
listed in BUG_ON() because it can be specified in the gfpflags to kmalloc
but also set by
On Tue, 2007-07-24 at 00:09 -0700, Christoph Lameter wrote:
> On Tue, 24 Jul 2007, Peter Zijlstra wrote:
>
> > Then we can either fixup the slab allocators to mask out __GFP_ZERO, or
> > do something like the below.
> >
> > Personally I like the consistency of adding __GFP_ZERO here (removes
> >
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
> > Personally I like the consistency of adding __GFP_ZERO here (removes
> > this odd exception) and just masking it in the sl[aou]b thingies.
Adds more code. GFP_LEVEL_MASK are the flags passed through to the
page allocator. Neither __GFP_ZERO nor
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
> Then we can either fixup the slab allocators to mask out __GFP_ZERO, or
> do something like the below.
>
> Personally I like the consistency of adding __GFP_ZERO here (removes
> this odd exception) and just masking it in the sl[aou]b thingies.
There
On Tue, 2007-07-24 at 08:01 +0200, Peter Zijlstra wrote:
> Then we can either fixup the slab allocators to mask out __GFP_ZERO, or
> do something like the below.
>
> Personally I like the consistency of adding __GFP_ZERO here (removes
> this odd exception) and just masking it in the sl[aou]b
On Mon, 2007-07-23 at 16:17 -0700, Christoph Lameter wrote:
> On Mon, 23 Jul 2007, Peter Zijlstra 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:
On Mon, 2007-07-23 at 16:17 -0700, Christoph Lameter wrote:
On Mon, 23 Jul 2007, Peter Zijlstra 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:
On Tue, 2007-07-24 at 08:01 +0200, Peter Zijlstra wrote:
Then we can either fixup the slab allocators to mask out __GFP_ZERO, or
do something like the below.
Personally I like the consistency of adding __GFP_ZERO here (removes
this odd exception) and just masking it in the sl[aou]b
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
Then we can either fixup the slab allocators to mask out __GFP_ZERO, or
do something like the below.
Personally I like the consistency of adding __GFP_ZERO here (removes
this odd exception) and just masking it in the sl[aou]b thingies.
There is
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
Personally I like the consistency of adding __GFP_ZERO here (removes
this odd exception) and just masking it in the sl[aou]b thingies.
Adds more code. GFP_LEVEL_MASK are the flags passed through to the
page allocator. Neither __GFP_ZERO nor
On Tue, 2007-07-24 at 00:09 -0700, Christoph Lameter wrote:
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
Then we can either fixup the slab allocators to mask out __GFP_ZERO, or
do something like the below.
Personally I like the consistency of adding __GFP_ZERO here (removes
this odd
On Tue, 24 Jul 2007, Peter Zijlstra wrote:
There is another exception for __GFP_DMA.
non of the zone specifiers are
__GFP_DMA is handled in a similar way to __GFP_ZERO though. Its explicitly
listed in BUG_ON() because it can be specified in the gfpflags to kmalloc
but also set by having
GFP_LEVEL_MASK is used to allow the pass through of page allocator
flags. Currently these are
#define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
__GFP_NOFAIL|__GFP_NORETRY|__GFP_COMP| \
On Tue, 24 Jul 2007 12:07:51 -0700
Christoph Lameter [EMAIL PROTECTED] wrote:
Then there are some other flags. I am wondering why they are in
GFP_LEVEL_MASK?
__GFP_COLDDoes not make sense for slab allocators since we have
to touch the page immediately.
__GFP_COMPNo
On Tue, 24 Jul 2007, Andrew Morton wrote:
__GFP_MOVABLE The movability of a slab is determined by the
options specified at kmem_cache_create time. If this is
specified at kmalloc time then we will have some random
slabs movable and others not.
On Tue, 24 Jul 2007 12:36:59 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Tue, 24 Jul 2007, Andrew Morton wrote:
__GFP_MOVABLE The movability of a slab is determined by the
options specified at kmem_cache_create time. If this is
specified at
On Tue, 24 Jul 2007, Andrew Morton wrote:
I think I'll duck this for now. Otherwise I have a suspicion that I'll
be the first person to run it and I'm too old for such excitement.
I always had the suspicion that you have some magical script
which will immediately tell you that a patch is not
On Tue, 24 Jul 2007 16:00:32 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Tue, 24 Jul 2007, Andrew Morton wrote:
I think I'll duck this for now. Otherwise I have a suspicion that I'll
be the first person to run it and I'm too old for such excitement.
I always had the
On Tue, 24 Jul 2007, Andrew Morton wrote:
__GFP_COMP I'm not so sure about.
drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like infiniband)
pass it into dma_alloc_coherent() which some architectures implement via
slab. umm,
arch/arm/mm/consistent.c is one such.
Should
On Tue, 24 Jul 2007 16:58:51 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Tue, 24 Jul 2007, Andrew Morton wrote:
__GFP_COMP I'm not so sure about.
drivers/char/drm/drm_pci.c:drm_pci_alloc() (and other places like
infiniband)
pass it into dma_alloc_coherent() which some
On Mon, 23 Jul 2007, Peter Zijlstra 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.
>
> This of course is in stark
On (23/07/07 13:38), Peter Zijlstra didst pronounce:
> On Mon, 2007-07-23 at 12:21 +0100, Mel Gorman wrote:
>
> > Does this patch compile though?
>
> Ugh, the fix landed in another patch :-(
>
> updated patch below.
>
> ---
> Daniel recently spotted that __GFP_ZERO is not (and has never been)
On Mon, 2007-07-23 at 12:21 +0100, Mel Gorman wrote:
> Does this patch compile though?
Ugh, the fix landed in another patch :-(
updated patch below.
---
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
On Mon, 2007-07-23 at 12:21 +0100, Mel Gorman wrote:
Does this patch compile though?
Ugh, the fix landed in another patch :-(
updated patch below.
---
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
On (23/07/07 13:38), Peter Zijlstra didst pronounce:
On Mon, 2007-07-23 at 12:21 +0100, Mel Gorman wrote:
Does this patch compile though?
Ugh, the fix landed in another patch :-(
updated patch below.
---
Daniel recently spotted that __GFP_ZERO is not (and has never been)
part of
On Mon, 23 Jul 2007, Peter Zijlstra 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.
This of course is in stark
36 matches
Mail list logo
