lkml.org 
[lkml]   [2002]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: page_alloc.c comments patch v2
> I got confused when I was examining the code and got mixed up. I see now
> the question about more that one ZONE_NORMAL in this pgdata_t is off, but
> the query still (sortof) holds. Let me try again.
>
> I am an allocator and I start in HIGHMEM which has a pages_low value of 10
> (arbitary number). I find I would hit it if I allocated from there so I
> move to NORMAL which also has a pages_low of 10 but now I am making sure I
> am at least 20 pages are free in the NORMAL zone, not 10 and possibly
> (presuming pages_low in DMA is 10) making sure 30 are free in DMA. Is this
> the way things are meant to happen?

Ah, OK, I see what you were getting at now ;-)

It's hard to really tell what was intended - Andrea might be able to give
you a
better idea. However, from the way I read the code, it might seem to make
more
sense if the "min = 1UL << order;" was inside the loop rather than outside.
That'd simply make sure we always left "zone->pages_low" free inside that
zone .... if course it would make no sense to assign min and then increment
it
with += inside the loop, or even set it any more .... just

if (z->free_pages > z->pages_low + (1UL << order))

But all that's purely speculation, he might have meant it as it is ;-)

M.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.042 / U:3.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site