kmem_cache_init() question

kmem_cache_init() question

[Prashanth C.]

Hi All,

This question is with reference to following segment of code [ver 2.2.9] in
kmem_cache_init() function (mm/slab.c):

if (num_physpages > (32 << 20) >> PAGE_SHIFT)
    slab_break_gfp_order = SLAB_BREAK_GFP_ORDER_HI;

I found that num_physpages is initialized in mem_init() function
(arch/i386/mm/init.c).  But start_kernel() calls kmem_cache_init() before
mem_init().  So, num_physpages will always(?) be zero when the above code
segment is executed.

Is num_physpages is initialized somewhere else before kmem_cache_init() is
called by start_kernel()?  Please let me know if I am missing something [if
my observation is indeed correct, then slab_break_gfp_order will never be
set to SLAB_BREAK_GFP_ORDER_HI].

Thanks a lot.

Prashanth.

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: kmem_cache_init() question

[Benjamin C.R. LaHaise]

On Tue, 15 Jun 1999, Prashanth C. wrote:

> This question is with reference to following segment of code [ver 2.2.9] in
> kmem_cache_init() function (mm/slab.c):
> 
> if (num_physpages > (32 << 20) >> PAGE_SHIFT)
>     slab_break_gfp_order = SLAB_BREAK_GFP_ORDER_HI;
> 
> I found that num_physpages is initialized in mem_init() function
> (arch/i386/mm/init.c).  But start_kernel() calls kmem_cache_init() before
> mem_init().  So, num_physpages will always(?) be zero when the above code
> segment is executed.

Interesting...  This was done as a work around for memory fragmentation in
low memory machines.  It was presumed that machines with lots of memory
did not have that problem, but if this code is actually moved to do what
it intended to do, the fragmentation problem might crop up again.  If
anyone changes this, put it into 2.3, not 2.2 -- perhaps a comment should
be added to slab.c pointing this out.

		-ben


--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: kmem_cache_init() question

[Stephen C. Tweedie]

Hi,

On Tue, 15 Jun 1999 13:39:12 +0530, "Prashanth C."
<cprash@wipinfo.soft.net> said:

> I found that num_physpages is initialized in mem_init() function
> (arch/i386/mm/init.c).  But start_kernel() calls kmem_cache_init() before
> mem_init().  So, num_physpages will always(?) be zero when the above code
> segment is executed.

> Is num_physpages is initialized somewhere else before kmem_cache_init() is
> called by start_kernel()?  

The great thing about having all the source code is that if you can't
instantly find the answer to such a question just by searching code, it
takes no time at all to add a 

	printk ("num_physpages is now %lu\n", num_physpages);

to init.c to find out for yourself. :)

And if this turns out to be a real bug, do let us know...

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: kmem_cache_init() question

[Benjamin C.R. LaHaise]

On Thu, 17 Jun 1999, Stephen C. Tweedie wrote:

> The great thing about having all the source code is that if you can't
> instantly find the answer to such a question just by searching code, it
> takes no time at all to add a 
> 
> 	printk ("num_physpages is now %lu\n", num_physpages);
> 
> to init.c to find out for yourself. :)
> 
> And if this turns out to be a real bug, do let us know...

It is a real bug, but it's one we probably don't want to fix in 2.2 unless
we want to deal with the fragmentation beast rearing its ugly head once
again. 

		-ben

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

RE: kmem_cache_init() question

[Prashanth C.]

> On Tue, 15 Jun 1999 13:39:12 +0530, "Prashanth C."
> <cprash@wipinfo.soft.net> said:
>
>> I found that num_physpages is initialized in mem_init() function
>> (arch/i386/mm/init.c).  But start_kernel() calls kmem_cache_init() before
>> mem_init().  So, num_physpages will always(?) be zero when the above code
>> segment is executed.
>
>> Is num_physpages is initialized somewhere else before kmem_cache_init()
is
>> called by start_kernel()?
>
> The great thing about having all the source code is that if you can't
> instantly find the answer to such a question just by searching code, it
> takes no time at all to add a
>
>	printk ("num_physpages is now %lu\n", num_physpages);
>
> to init.c to find out for yourself. :)
>
> And if this turns out to be a real bug, do let us know...
>
> --Stephen

Yes, it is a bug.  Infact I found this bug when I tried to print values of
few varibles in kmem_cache_init() using printk().  Since, I have just now
started getting familiar with the MM code, I was not sure if I was missing
something :)

- Prashanth

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/