On 1/24/07, Christoph Lameter <clameter@xxxxxxx> wrote:
On Wed, 24 Jan 2007, Nick Piggin wrote:Sorry for the delay. Somehow this thread was put into the spam folder
> > 1. Insure that anonymous pages that may contain performance
> > critical data is never subject to swap.
> >
> > 2. Insure rapid turnaround of pages in the cache.
>
> So if these two aren't working properly at 100%, then I want to know the
> reason why. Or at least see what the workload and the numbers look like.
The reason for the anonymous page may be because data is rarely touched
but for some reason the pages must stay in memory. Rapid turnaround is
just one of the reason that I vaguely recall but I never really
understood what the purpose was.
> > 3. Reserve memory for other uses? (Aubrey?)
>
> Maybe. This is still a bad hack, and I don't like to legitimise such use
> though. I hope Aubrey isn't relying on this alone for his device to work
> because his customers might end up hitting fragmentation problems sooner
> or later.
I surely wish that Aubrey would give us some more clarity on
how this should work. Maybe the others who want this feature could also
speak up? I am not that clear on its purpose.
of my gmail box. :(
The patch I posted several days ago works properly on my side. I'm
working on blackfin-uclinux platform. So I'm not sure it works 100% on
the other arch platform. From O_DIRECT threads, I know different
people suffer from VFS pagecache issue for different reason. So I
really hope the patch can be improved.
On my side, When VFS pagecache eat up all of the available memory,
applications who want to allocate the largeish block(order =4 ?) will
fail. So the logic is as follows:
I hope Aubrey isn't relying on this alone for his device to work
because his customers might end up hitting fragmentation problems sooner
or later.
That's true. I wrote a replacement of buddy system, it's here:
http://lkml.org/lkml/2006/12/30/36.
That can improve the fragmentation problems on our platform.