Hi Pavel
> > > As user pages are always in highmem, this should be easy to decide:
> > > only send SIGDANGER when highmem is full. (Yes, there are
> > > inodes/dentries/file descriptors in lowmem, but I doubt apps will
> > > respond to SIGDANGER by closing files).
> >
> > Good point; for a system
Hi Jon
> I looked at this a year or two back, then ran out of time. But the thing
> I wanted to do was have libc's memory allocation routines extended to
> handle these through reservations - the kernel should send a userspace
> notification and then there should be some kind of concept of
Hi Jon
I looked at this a year or two back, then ran out of time. But the thing
I wanted to do was have libc's memory allocation routines extended to
handle these through reservations - the kernel should send a userspace
notification and then there should be some kind of concept of returning
Hi Pavel
As user pages are always in highmem, this should be easy to decide:
only send SIGDANGER when highmem is full. (Yes, there are
inodes/dentries/file descriptors in lowmem, but I doubt apps will
respond to SIGDANGER by closing files).
Good point; for a system with at least
On Mon, 28 Jan 2008, Theodore Tso wrote:
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
As user pages are always in highmem, this should be easy to decide:
only send SIGDANGER when highmem is full. (Yes, there are
inodes/dentries/file descriptors in lowmem, but I doubt apps
On Sat, 2008-01-26 at 16:55 +0300, Al Boldi wrote:
> KOSAKI Motohiro wrote:
> > > > And from a performance point of view letting applications voluntarily
> > > > free some memory is better even than starting to swap.
> > >
> > > Absolutely.
> >
> > the mem_notify patch can realize "just before
On Mon 2008-01-28 14:56:33, Theodore Tso wrote:
> On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
> >
> > As user pages are always in highmem, this should be easy to decide:
> > only send SIGDANGER when highmem is full. (Yes, there are
> > inodes/dentries/file descriptors in lowmem,
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
>
> As user pages are always in highmem, this should be easy to decide:
> only send SIGDANGER when highmem is full. (Yes, there are
> inodes/dentries/file descriptors in lowmem, but I doubt apps will
> respond to SIGDANGER by closing
Hi!
> It's been discussed before, but I suspect the main reason why it was
> never done is no one submitted a patch. Also, the problem is actually
> a pretty complex one. There are a couple of different stages where
> you might want to send an alert to processes:
>
> * Data is starting to
Hi!
It's been discussed before, but I suspect the main reason why it was
never done is no one submitted a patch. Also, the problem is actually
a pretty complex one. There are a couple of different stages where
you might want to send an alert to processes:
* Data is starting to get
On Mon 2008-01-28 14:56:33, Theodore Tso wrote:
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
As user pages are always in highmem, this should be easy to decide:
only send SIGDANGER when highmem is full. (Yes, there are
inodes/dentries/file descriptors in lowmem, but I
On Sat, 2008-01-26 at 16:55 +0300, Al Boldi wrote:
KOSAKI Motohiro wrote:
And from a performance point of view letting applications voluntarily
free some memory is better even than starting to swap.
Absolutely.
the mem_notify patch can realize just before starting swapping
On Mon, 28 Jan 2008, Theodore Tso wrote:
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
As user pages are always in highmem, this should be easy to decide:
only send SIGDANGER when highmem is full. (Yes, there are
inodes/dentries/file descriptors in lowmem, but I doubt apps
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
As user pages are always in highmem, this should be easy to decide:
only send SIGDANGER when highmem is full. (Yes, there are
inodes/dentries/file descriptors in lowmem, but I doubt apps will
respond to SIGDANGER by closing
Hi Al
> > the mem_notify patch can realize "just before starting swapping"
> > notification :)
> >
> > to be honest, I don't know fs guys requirement.
> > if lacking feature of fs guys needed, I implement it with presure if
> > you tell me it.
>
> These notifications are really useful, but it may
KOSAKI Motohiro wrote:
> > > And from a performance point of view letting applications voluntarily
> > > free some memory is better even than starting to swap.
> >
> > Absolutely.
>
> the mem_notify patch can realize "just before starting swapping"
> notification :)
>
> to be honest, I don't know
On Fri, Jan 25, 2008 at 05:55:51PM -0800, Bryan Henderson wrote:
> I was surprised to see AIX do late allocation by default, because IBM's
> traditional style is bulletproof systems. A system where a process can be
> killed at unpredictable times because of resource demands of unrelated
>
> > And from a performance point of view letting applications voluntarily
> > free some memory is better even than starting to swap.
>
> Absolutely.
the mem_notify patch can realize "just before starting swapping" notification :)
to be honest, I don't know fs guys requirement.
if lacking feature
> The commentary on the mem_notify threads claimed that the signal is
> easily provided by setting up the file handle for SIGIO.
BTW:
Of cource, you can receive any signal instead SIGIO by use fcntl(F_SETSIG) :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
The commentary on the mem_notify threads claimed that the signal is
easily provided by setting up the file handle for SIGIO.
BTW:
Of cource, you can receive any signal instead SIGIO by use fcntl(F_SETSIG) :-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
And from a performance point of view letting applications voluntarily
free some memory is better even than starting to swap.
Absolutely.
the mem_notify patch can realize just before starting swapping notification :)
to be honest, I don't know fs guys requirement.
if lacking feature of fs
On Fri, Jan 25, 2008 at 05:55:51PM -0800, Bryan Henderson wrote:
I was surprised to see AIX do late allocation by default, because IBM's
traditional style is bulletproof systems. A system where a process can be
killed at unpredictable times because of resource demands of unrelated
Hi Al
the mem_notify patch can realize just before starting swapping
notification :)
to be honest, I don't know fs guys requirement.
if lacking feature of fs guys needed, I implement it with presure if
you tell me it.
These notifications are really useful, but it may be much wiser
>> Incidentally, some context for the AIX approach to the OOM problem: a
>> process may exclude itself from OOM vulnerability altogether. It
places
>> itself in "early allocation" mode, which means at the time it creates
>> virtual memory, it reserves enough backing store for the worst case.
On Fri, 2008-01-25 at 04:09 -0700, Andreas Dilger wrote:
> On Jan 24, 2008 17:25 -0700, Zan Lynx wrote:
> > Have y'all been following the /dev/mem_notify patches?
> > http://article.gmane.org/gmane.linux.kernel/628653
>
> Having the notification be via poll() is a very restrictive processing
>
On Jan 24, 2008 17:25 -0700, Zan Lynx wrote:
> Have y'all been following the /dev/mem_notify patches?
> http://article.gmane.org/gmane.linux.kernel/628653
Having the notification be via poll() is a very restrictive processing
model. Having the notification be via a signal means that any kind of
Incidentally, some context for the AIX approach to the OOM problem: a
process may exclude itself from OOM vulnerability altogether. It
places
itself in early allocation mode, which means at the time it creates
virtual memory, it reserves enough backing store for the worst case.
The
On Jan 24, 2008 17:25 -0700, Zan Lynx wrote:
Have y'all been following the /dev/mem_notify patches?
http://article.gmane.org/gmane.linux.kernel/628653
Having the notification be via poll() is a very restrictive processing
model. Having the notification be via a signal means that any kind of
On Thu, 2008-01-24 at 18:40 -0500, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> > In practice, there is a small number of programs that are both the
> > common memory hogs and should be able to reduce their memory consumption
> > by 10% or 20% without big
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> In practice, there is a small number of programs that are both the
> common memory hogs and should be able to reduce their memory consumption
> by 10% or 20% without big problems when requested (e.g. Java VMs,
> Firefox and databases
On Thu, Jan 24, 2008 at 06:32:15PM +0100, Bodo Eggert wrote:
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> >> I'd tried to advocate SIGDANGER some years ago as well, but none of
> >> the kernel maintainers were interested. It definitely makes sense
> >> to have some sort of mechanism like this. At
On Jan 24, 2008 18:32 +0100, Bodo Eggert wrote:
> I think a single, system-wide signal is the second-to worst solution: All
> applications (or the wrong one, if you select one) would free their caches
> and start to crawl, and either stay in this state or slowly increase their
> caches again
Alan Cox <[EMAIL PROTECTED]> wrote:
>> I'd tried to advocate SIGDANGER some years ago as well, but none of
>> the kernel maintainers were interested. It definitely makes sense
>> to have some sort of mechanism like this. At the time I first brought
>> it up it was in conjunction with Netscape
Alan Cox [EMAIL PROTECTED] wrote:
I'd tried to advocate SIGDANGER some years ago as well, but none of
the kernel maintainers were interested. It definitely makes sense
to have some sort of mechanism like this. At the time I first brought
it up it was in conjunction with Netscape using too
On Jan 24, 2008 18:32 +0100, Bodo Eggert wrote:
I think a single, system-wide signal is the second-to worst solution: All
applications (or the wrong one, if you select one) would free their caches
and start to crawl, and either stay in this state or slowly increase their
caches again until
On Thu, Jan 24, 2008 at 06:32:15PM +0100, Bodo Eggert wrote:
Alan Cox [EMAIL PROTECTED] wrote:
I'd tried to advocate SIGDANGER some years ago as well, but none of
the kernel maintainers were interested. It definitely makes sense
to have some sort of mechanism like this. At the time I
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
In practice, there is a small number of programs that are both the
common memory hogs and should be able to reduce their memory consumption
by 10% or 20% without big problems when requested (e.g. Java VMs,
Firefox and databases come
On Thu, 2008-01-24 at 18:40 -0500, Theodore Tso wrote:
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
In practice, there is a small number of programs that are both the
common memory hogs and should be able to reduce their memory consumption
by 10% or 20% without big problems
>I think there is a clear need for applications to be able to
>register a callback from the kernel to indicate that the machine as
>a whole is running out of memory and that the application should
>trim it's caches to reduce memory utilisation.
>
>Perhaps instead of swapping immediately, a
Em Tue, Jan 22, 2008 at 09:40:52AM -0500, Theodore Tso escreveu:
> On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
> > > AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
> > > the system was about to hit OOM, not when it was about to start swapping.
> >
> > I'd
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
> > AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
> > the system was about to hit OOM, not when it was about to start swapping.
>
> I'd tried to advocate SIGDANGER some years ago as well, but none of
> the
> I'd tried to advocate SIGDANGER some years ago as well, but none of
> the kernel maintainers were interested. It definitely makes sense
> to have some sort of mechanism like this. At the time I first brought
> it up it was in conjunction with Netscape using too much cache on some
> system, but
On Tue, Jan 22, 2008 at 12:05:11AM -0700, Andreas Dilger wrote:
> On Jan 22, 2008 14:38 +1100, David Chinner wrote:
> > On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
> > > I discussed this with Ted at one point also. This is a generic problem,
> > > not just for readahead,
On Tue, Jan 22, 2008 at 12:05:11AM -0700, Andreas Dilger wrote:
On Jan 22, 2008 14:38 +1100, David Chinner wrote:
On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
I discussed this with Ted at one point also. This is a generic problem,
not just for readahead, because fsck
I'd tried to advocate SIGDANGER some years ago as well, but none of
the kernel maintainers were interested. It definitely makes sense
to have some sort of mechanism like this. At the time I first brought
it up it was in conjunction with Netscape using too much cache on some
system, but it
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
the system was about to hit OOM, not when it was about to start swapping.
I'd tried to advocate SIGDANGER some years ago as well, but none of
the kernel
Em Tue, Jan 22, 2008 at 09:40:52AM -0500, Theodore Tso escreveu:
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
the system was about to hit OOM, not when it was about to start swapping.
I'd tried to
I think there is a clear need for applications to be able to
register a callback from the kernel to indicate that the machine as
a whole is running out of memory and that the application should
trim it's caches to reduce memory utilisation.
Perhaps instead of swapping immediately, a SIGLOWMEM
On Jan 22, 2008 14:38 +1100, David Chinner wrote:
> On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
> > I discussed this with Ted at one point also. This is a generic problem,
> > not just for readahead, because "fsck" can run multiple e2fsck in parallel
> > and in case of many
On Jan 21, 2008 23:17 -0500, [EMAIL PROTECTED] wrote:
> On Tue, 22 Jan 2008 14:38:30 +1100, David Chinner said:
> > Perhaps instead of swapping immediately, a SIGLOWMEM could be sent
> > to a processes that aren't masking the signal followed by a short
> > grace period to allow the processes to
On Tue, 22 Jan 2008 14:38:30 +1100, David Chinner said:
> Perhaps instead of swapping immediately, a SIGLOWMEM could be sent
> to a processes that aren't masking the signal followed by a short
> grace period to allow the processes to free up some memory before
> swapping out pages from that
On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
> On Jan 16, 2008 13:30 -0800, Valerie Henson wrote:
> > I have a partial solution that sort of blindly manages the buffer
> > cache. First, the user passes e2fsck a parameter saying how much
> > memory is available as buffer cache.
On Jan 16, 2008 13:30 -0800, Valerie Henson wrote:
> I have a partial solution that sort of blindly manages the buffer
> cache. First, the user passes e2fsck a parameter saying how much
> memory is available as buffer cache. The readahead thread reads
> things in and immediately throws them
On Jan 16, 2008 13:30 -0800, Valerie Henson wrote:
I have a partial solution that sort of blindly manages the buffer
cache. First, the user passes e2fsck a parameter saying how much
memory is available as buffer cache. The readahead thread reads
things in and immediately throws them away so
On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
On Jan 16, 2008 13:30 -0800, Valerie Henson wrote:
I have a partial solution that sort of blindly manages the buffer
cache. First, the user passes e2fsck a parameter saying how much
memory is available as buffer cache. The
On Jan 21, 2008 23:17 -0500, [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008 14:38:30 +1100, David Chinner said:
Perhaps instead of swapping immediately, a SIGLOWMEM could be sent
to a processes that aren't masking the signal followed by a short
grace period to allow the processes to free up
On Jan 22, 2008 14:38 +1100, David Chinner wrote:
On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
I discussed this with Ted at one point also. This is a generic problem,
not just for readahead, because fsck can run multiple e2fsck in parallel
and in case of many large
On Jan 17, 2008 5:15 PM, David Chinner <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 16, 2008 at 01:30:43PM -0800, Valerie Henson wrote:
> > Hi y'all,
> >
> > This is a request for comments on the rewrite of the e2fsck IO
> > parallelization patches I sent out a few months ago. The mechanism is
> >
On Wed, Jan 16, 2008 at 01:30:43PM -0800, Valerie Henson wrote:
> Hi y'all,
>
> This is a request for comments on the rewrite of the e2fsck IO
> parallelization patches I sent out a few months ago. The mechanism is
> totally different. Previously IO was parallelized by issuing IOs from
>
On Wed, Jan 16, 2008 at 01:30:43PM -0800, Valerie Henson wrote:
Hi y'all,
This is a request for comments on the rewrite of the e2fsck IO
parallelization patches I sent out a few months ago. The mechanism is
totally different. Previously IO was parallelized by issuing IOs from
multiple
On Jan 17, 2008 5:15 PM, David Chinner [EMAIL PROTECTED] wrote:
On Wed, Jan 16, 2008 at 01:30:43PM -0800, Valerie Henson wrote:
Hi y'all,
This is a request for comments on the rewrite of the e2fsck IO
parallelization patches I sent out a few months ago. The mechanism is
totally
61 matches
Mail list logo
