On Fri, 26 Jan 2007 02:29:55 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Jan 2007 14:15:10 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > - One for stability
> > When a customer constructs their detabase(Oracle), the system often goes
> > to oom.
> > This is becau
On Wed, 24 Jan 2007 15:03:23 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Yeah, it will be failing at order=4, because the allocator won't try
> very hard reclaim pagecache pages at that cutoff point. This needs to
> be fixed in the allocator.
A simple and perhaps sufficient fix for this nom
On Wed, 24 Jan 2007 14:15:10 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> - One for stability
> When a customer constructs their detabase(Oracle), the system often goes to
> oom.
> This is because that the system cannot allocate DMA_ZOME memory for 32bit
> device.
> (USB or e100)
>
Al Boldi wrote:
> Vaidyanathan Srinivasan wrote:
>> Al Boldi wrote:
>>> Rik van Riel wrote:
Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is
> IMHO the right way. Feel free to improve on it. I have gotten
> repeatedly requests to be ab
Rik van Riel wrote:
Vaidyanathan Srinivasan wrote:
Rik van Riel wrote:
There are a few databases out there that mmap the whole
thing. Sleepycat for one...
That is why my suggestion would be not to touch mmapped pagecache
pages in the current pagecache limit code. The limit should concern
Vaidyanathan Srinivasan wrote:
Rik van Riel wrote:
There are a few databases out there that mmap the whole
thing. Sleepycat for one...
That is why my suggestion would be not to touch mmapped pagecache
pages in the current pagecache limit code. The limit should concern
only unmapped pagecac
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
>> On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>> > He wants to make a nommu system act like a mmu system; this will just
>> > never ever work.
>>
>> Nope. Actually my nommu system works grea
Vaidyanathan Srinivasan wrote:
> Al Boldi wrote:
> > Rik van Riel wrote:
> >> Christoph Lameter wrote:
> >>> This is a patch using some of Aubrey's work plugging it in what is
> >>> IMHO the right way. Feel free to improve on it. I have gotten
> >>> repeatedly requests to be able to limit the pagec
Peter Zijlstra wrote:
> > Apart from kswapd, limiting pagecache helps performance of
> > applications by not eating away their ANON pages or other parts of its
> > resident data set. When there is enough free memory, then there is no
> > performance issue. However memory is always utilized to the
Peter Zijlstra wrote:
>> Apart from kswapd, limiting pagecache helps performance of
>> applications by not eating away their ANON pages or other parts of its
>> resident data set. When there is enough free memory, then there is no
>> performance issue. However memory is always utilized to the m
> Apart from kswapd, limiting pagecache helps performance of
> applications by not eating away their ANON pages or other parts of its
> resident data set. When there is enough free memory, then there is no
> performance issue. However memory is always utilized to the max.
> Hence every pagecache
Al Boldi wrote:
> Rik van Riel wrote:
>> Christoph Lameter wrote:
>>> This is a patch using some of Aubrey's work plugging it in what is IMHO
>>> the right way. Feel free to improve on it. I have gotten repeatedly
>>> requests to be able to limit the pagecache.
>> IMHO it's a bad hack.
>>
>> It w
Christoph Lameter wrote:
> On Wed, 24 Jan 2007, Erik Andersen wrote:
>
>> It would be far more useful if an application could hint to the
>> pagecache as to which files are and which files as not worth
>> caching, especially when the application knows a priori that data
>> from a particular file
Aubrey Li wrote:
> On 1/25/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
>>
>> Christoph Lameter wrote:
>>> On Wed, 24 Jan 2007, Vaidyanathan Srinivasan wrote:
>>>
With your patch, MMAP of a file that will cross the pagecache limit hangs
the
system. As I mentioned in my
On Thu, 25 Jan 2007, Aubrey Li wrote:
> But Vaidy - even with your patch, we are still using the existing
> reclaimer, that means we dont ensure that only page cache is
> reclaimed/limited. mapped pages will be hit also.
> I think we still need to add a new scancontrol field to lock mmaped
> pages
Rik van Riel wrote:
> Christoph Lameter wrote:
> > This is a patch using some of Aubrey's work plugging it in what is IMHO
> > the right way. Feel free to improve on it. I have gotten repeatedly
> > requests to be able to limit the pagecache.
>
> IMHO it's a bad hack.
>
> It would be better to iden
On 1/25/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
Christoph Lameter wrote:
> On Wed, 24 Jan 2007, Vaidyanathan Srinivasan wrote:
>
>> With your patch, MMAP of a file that will cross the pagecache limit hangs the
>> system. As I mentioned in my previous mail, without subtracting th
On Thu, 25 Jan 2007 00:40:54 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
> > On Wed, 24 Jan 2007 23:28:15 -0500
> > Rik van Riel <[EMAIL PROTECTED]> wrote:
> >
> >> KAMEZAWA Hiroyuki wrote:
> > I always says Linux is different from mainframes.
>
> It's not just about
Rik van Riel wrote:
> Vaidyanathan Srinivasan wrote:
>
>> In my opinion, once a
>> file page is mapped by the process, then it should be treated at par
>> with anon pages. Application programs generally do not mmap a file
>> page if the reuse for the content is very low.
>
> Why not have the V
KAMEZAWA Hiroyuki wrote:
On Wed, 24 Jan 2007 23:28:15 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
KAMEZAWA Hiroyuki wrote:
FYI:
Because some customers are migrated from mainframes, they want to control
almost all features in OS, IOW, designing memory usages.
Don't you mean:
"Because some
On Wed, 24 Jan 2007 23:28:15 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
> KAMEZAWA Hiroyuki wrote:
>
> > FYI:
> > Because some customers are migrated from mainframes, they want to control
> > almost all features in OS, IOW, designing memory usages.
>
> Don't you mean:
>
> "Because some custo
Vaidyanathan Srinivasan wrote:
In my opinion, once a
file page is mapped by the process, then it should be treated at par
with anon pages. Application programs generally do not mmap a file
page if the reuse for the content is very low.
Why not have the VM measure this, instead of making wild
KAMEZAWA Hiroyuki wrote:
FYI:
Because some customers are migrated from mainframes, they want to control
almost all features in OS, IOW, designing memory usages.
Don't you mean:
"Because some customers are migrating from mainframes, they are
used to needing to control all features in OS" ? :)
Christoph Lameter wrote:
This is a patch using some of Aubrey's work plugging it in what is IMHO
the right way. Feel free to improve on it. I have gotten repeatedly
requests to be able to limit the pagecache.
IMHO it's a bad hack.
It would be better to identify the problem this "feature" is
Christoph Lameter wrote:
> On Wed, 24 Jan 2007, Vaidyanathan Srinivasan wrote:
>
>> With your patch, MMAP of a file that will cross the pagecache limit hangs the
>> system. As I mentioned in my previous mail, without subtracting the
>> NR_FILE_MAPPED, the reclaim will infinitely try and fail.
>
On Wed, 24 Jan 2007 18:41:27 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > But I can't think of the way to show that.
> > ==
> > [EMAIL PROTECTED] src]$ free
> > total used free sharedbuffers cached
> > Mem:741604 724628 16976
On Wed, 24 Jan 2007, Erik Andersen wrote:
> It would be far more useful if an application could hint to the
> pagecache as to which files are and which files as not worth
> caching, especially when the application knows a priori that data
> from a particular file will or will not ever be reused.
On Thu, 25 Jan 2007, KAMEZAWA Hiroyuki wrote:
> On Wed, 24 Jan 2007 14:15:10 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > And...some customers want to keep memory Free as much as possible.
> > 99% memory usage makes insecure them ;)
> >
> If there is a way that the "free" comma
On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
> On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
> > > This is a patch using some of Aubrey's work plugging it in what i
On Wed, 24 Jan 2007 14:15:10 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> And...some customers want to keep memory Free as much as possible.
> 99% memory usage makes insecure them ;)
>
If there is a way that the "free" command can show "never used" memory,
they will not complain ;).
On Wed Jan 24, 2007 at 06:58:42AM -0800, Christoph Lameter wrote:
> On Wed, 24 Jan 2007, Nick Piggin wrote:
>
> > I can't argue that a smaller pagecache will be subject to a
> > higher turnaround given the same workload, but I don't know why
> > that would be a good thing.
>
> Neither do I. Wonde
On Wed, 24 Jan 2007, Nick Piggin wrote:
> I can't argue that a smaller pagecache will be subject to a
> higher turnaround given the same workload, but I don't know why
> that would be a good thing.
Neither do I. Wonder why we need this but I keep getting
these requests. Could we either find a re
On Wed, 24 Jan 2007, Vaidyanathan Srinivasan wrote:
> With your patch, MMAP of a file that will cross the pagecache limit hangs the
> system. As I mentioned in my previous mail, without subtracting the
> NR_FILE_MAPPED, the reclaim will infinitely try and fail.
Well mapped pages are still pageca
On Wed, 2007-01-24 at 22:22 +0800, Aubrey Li wrote:
> On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
> > > This is a patch using some of Aubrey's work plugging it in what is IMHO
> > > the right way. Feel free to improve on it.
On 1/24/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is IMHO
> the right way. Feel free to improve on it. I have gotten repeatedly
> requests to be able to limit the page
On Wed, 2007-01-24 at 23:50 +1100, Nick Piggin wrote:
> Peter Zijlstra wrote:
> > On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
>
> >>2. Insure rapid turnaround of pages in the cache.
>
> [...]
>
> > The only maybe valid point would be 2, and I'd like to see if we can't
> > solve
Peter Zijlstra wrote:
On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
2. Insure rapid turnaround of pages in the cache.
[...]
The only maybe valid point would be 2, and I'd like to see if we can't
solve that differently - a better use-once logic comes to mind.
There must be
Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is IMHO
> the right way. Feel free to improve on it. I have gotten repeatedly
> requests to be able to limit the pagecache. With the revised VM statistics
> this is now actually possile. I'd like to know mo
On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is IMHO
> the right way. Feel free to improve on it. I have gotten repeatedly
> requests to be able to limit the pagecache. With the revised VM statistics
> this is now a
Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is IMHO
> the right way. Feel free to improve on it. I have gotten repeatedly
> requests to be able to limit the pagecache. With the revised VM statistics
> this is now actually possile. I'd like to know mo
Christoph's patch is better than mine. The only thing I think is that
zone->max_pagecache_pages should be checked never less than
zone->pages_low.
The good part of the patch is using the existing reclaimer. But the
problem in my opinion of the idea is the existing reclaimer too. Think
of when vf
On Tue, 23 Jan 2007 20:30:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 24 Jan 2007, KAMEZAWA Hiroyuki wrote:
>
> > I don't prefer to cause zone fallback by this.
> > This may use ZONE_DMA before exhausing ZONE_NORMAL (ia64),
>
> Hmmm... We could use node_page_state inste
On Wed, 24 Jan 2007, KAMEZAWA Hiroyuki wrote:
> I don't prefer to cause zone fallback by this.
> This may use ZONE_DMA before exhausing ZONE_NORMAL (ia64),
Hmmm... We could use node_page_state instead of zone_page_state.
> Very rapid page allocation can eats some amount of lower zone.
One quest
Aubrey Li wrote:
On 1/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Wed, 24 Jan 2007, Nick Piggin wrote:
> > 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 t
On 1/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Wed, 24 Jan 2007, Nick Piggin wrote:
> > 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 wor
one more thing...
On Tue, 23 Jan 2007 16:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> @@ -1168,6 +1170,11 @@ zonelist_scan:
> !cpuset_zone_allowed_softwall(zone, gfp_mask))
> goto try_next_zone;
>
> + if ((gfp_
On Wed, 24 Jan 2007, Nick Piggin wrote:
> > 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 w
On Wed, 24 Jan 2007, KAMEZAWA Hiroyuki wrote:
> if (sc->may_swap &&
> zone_page_state(zone, NR_FILE_PAGES) &&
> !(curreht->flags & PF_MEMALLOC))
> sc->may_swap = 0;
That is probably better than what we have so far.
-
To unsubscribe from this list: send the line "unsubscribe linux-k
Christoph Lameter wrote:
This is a patch using some of Aubrey's work plugging it in what is IMHO
the right way. Feel free to improve on it. I have gotten repeatedly
requests to be able to limit the pagecache. With the revised VM statistics
this is now actually possile. I'd like to know more abo
On Tue, 23 Jan 2007 16:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> If we enter reclaim and the number of page cache pages
> is too high then we switch off swapping during reclaim
> to avoid touching anonymous pages.
In general, I like this (kind of) feature.
> + /*
> +
This is a patch using some of Aubrey's work plugging it in what is IMHO
the right way. Feel free to improve on it. I have gotten repeatedly
requests to be able to limit the pagecache. With the revised VM statistics
this is now actually possile. I'd like to know more about possible uses of
such
51 matches
Mail list logo
