On Thu, 4 Jan 2007, Pekka J Enberg wrote:
> Something like this (totally untested) patch?
Yup. Moving the GFP_WAIT processing into kmem_getpages() will clean up a
lot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Hi Christoph,
On Thu, 4 Jan 2007, Christoph Lameter wrote:
> Good idea if you can make it so that it is clean. There is some
> additional processing in cache_grow() that would have to be taken into
> account.
Something like this (totally untested) patch?
diff --git a/mm/slab.c b/mm/slab.c
On 1/4/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
That does indeed look more tasteful. But there appears to be a fair
bit more refactoring one would want to do, if aiming for good taste
there: the kmem_flagcheck, the conditional local_irq_dis/enable...
I think I'll leave that to you and
On Thu, 4 Jan 2007, Pekka Enberg wrote:
> Hi Hugh,
>
> [Sorry, no access to kernel tree right now, so can't send a patch.]
>
> On 1/4/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > @@ -3310,7 +3310,7 @@ retry:
> > */
> >
On Thu, 4 Jan 2007, Pekka Enberg wrote:
> So, how about we rename the current cache_grow() to __cache_grow() and
> move the kmem_freepages() to a higher level function like this:
>
> static int cache_grow(struct kmem_cache *cache,
>gfp_t flags, int nodeid)
> {
>
On Thu, 4 Jan 2007, Hugh Dickins wrote:
> Fixes a CONFIG_NUMA regression introduced in 2.6.20-rc1. Or you may
> feel it's cleaner for cache_grow to skip its kmem_freepages when objp
> is input: patch below is slightly simpler, but I've no strong feeling.
Acked-by: Christoph Lameter <[EMAIL
Hi Hugh,
[Sorry, no access to kernel tree right now, so can't send a patch.]
On 1/4/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
@@ -3310,7 +3310,7 @@ retry:
*/
goto retry;
} else {
-
pdflush hit the BUG_ON(!PageSlab(page)) in kmem_freepages called from
fallback_alloc: cache_grow already freed those pages when alloc_slabmgmt
failed. But it wouldn't have freed them if __GFP_NO_GROW, so make sure
fallback_alloc doesn't waste its time on that case.
Signed-off-by: Hugh Dickins
pdflush hit the BUG_ON(!PageSlab(page)) in kmem_freepages called from
fallback_alloc: cache_grow already freed those pages when alloc_slabmgmt
failed. But it wouldn't have freed them if __GFP_NO_GROW, so make sure
fallback_alloc doesn't waste its time on that case.
Signed-off-by: Hugh Dickins
Hi Hugh,
[Sorry, no access to kernel tree right now, so can't send a patch.]
On 1/4/07, Hugh Dickins [EMAIL PROTECTED] wrote:
@@ -3310,7 +3310,7 @@ retry:
*/
goto retry;
} else {
-
On Thu, 4 Jan 2007, Hugh Dickins wrote:
Fixes a CONFIG_NUMA regression introduced in 2.6.20-rc1. Or you may
feel it's cleaner for cache_grow to skip its kmem_freepages when objp
is input: patch below is slightly simpler, but I've no strong feeling.
Acked-by: Christoph Lameter [EMAIL
On Thu, 4 Jan 2007, Pekka Enberg wrote:
So, how about we rename the current cache_grow() to __cache_grow() and
move the kmem_freepages() to a higher level function like this:
static int cache_grow(struct kmem_cache *cache,
gfp_t flags, int nodeid)
{
On Thu, 4 Jan 2007, Pekka Enberg wrote:
Hi Hugh,
[Sorry, no access to kernel tree right now, so can't send a patch.]
On 1/4/07, Hugh Dickins [EMAIL PROTECTED] wrote:
@@ -3310,7 +3310,7 @@ retry:
*/
goto
On 1/4/07, Hugh Dickins [EMAIL PROTECTED] wrote:
That does indeed look more tasteful. But there appears to be a fair
bit more refactoring one would want to do, if aiming for good taste
there: the kmem_flagcheck, the conditional local_irq_dis/enable...
I think I'll leave that to you and
Hi Christoph,
On Thu, 4 Jan 2007, Christoph Lameter wrote:
Good idea if you can make it so that it is clean. There is some
additional processing in cache_grow() that would have to be taken into
account.
Something like this (totally untested) patch?
diff --git a/mm/slab.c b/mm/slab.c
index
On Thu, 4 Jan 2007, Pekka J Enberg wrote:
Something like this (totally untested) patch?
Yup. Moving the GFP_WAIT processing into kmem_getpages() will clean up a
lot.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
16 matches
Mail list logo
