Re: /proc/sys/vm/freepages not writable.
On Tue, Sep 19, 2000 at 04:52:25AM -0300, Rik van Riel wrote: > > I don't like self tuning algorithms for this case, because they > > tend to cause a disruption on the first spike (e.g. causing lots > > of packets dropped first until the VM can adapt). When the admin > > says "I don't care if 10MB are wasted, I want it this way" > > explicitely he should get his will. > > Indeed, you are right. I'll add this feature shortly. It would be nice if you could do it via freepages again, then documentation would not need to be rewriten. Even if some of the numbers are meaningless now, e.g. the middle number could give a goal for the VM. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Mon, 18 Sep 2000, Andi Kleen wrote: > On Sun, Sep 17, 2000 at 03:53:47PM -0300, Rik van Riel wrote: > > On Sun, 17 Sep 2000, Andi Kleen wrote: > > > On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: > > > > > > 1. The inactive_target is 1 second worth of allocations, minus > > > >the amount of frees in 1 second, averaged over a minute > > > > > > So it cannot take load bursts. That's ok for a default, but for > > > special loads it would be good if there was a way for the > > > administrator to overwrite that, similar to the old freepages. > > > > OK, lets see if we can come up with some nice (self-tuning?) > > idea for this at Linux Kongress ;) > > I don't like self tuning algorithms for this case, because they > tend to cause a disruption on the first spike (e.g. causing lots > of packets dropped first until the VM can adapt). When the admin > says "I don't care if 10MB are wasted, I want it this way" > explicitely he should get his will. Indeed, you are right. I'll add this feature shortly. Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Mon, 18 Sep 2000, Andi Kleen wrote: On Sun, Sep 17, 2000 at 03:53:47PM -0300, Rik van Riel wrote: On Sun, 17 Sep 2000, Andi Kleen wrote: On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: 1. The inactive_target is 1 second worth of allocations, minus the amount of frees in 1 second, averaged over a minute So it cannot take load bursts. That's ok for a default, but for special loads it would be good if there was a way for the administrator to overwrite that, similar to the old freepages. OK, lets see if we can come up with some nice (self-tuning?) idea for this at Linux Kongress ;) I don't like self tuning algorithms for this case, because they tend to cause a disruption on the first spike (e.g. causing lots of packets dropped first until the VM can adapt). When the admin says "I don't care if 10MB are wasted, I want it this way" explicitely he should get his will. Indeed, you are right. I'll add this feature shortly. Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
In article <[EMAIL PROTECTED]> you wrote: > How about taking a decaying average (loadavg style) of the peak allocation-free why? I think it is not a bad thing if you have some kind of setting like "irq heavy system" <-> "applicaion heavy system" even in NT you hve this slider. The current problem we have with linux that it is hard to tune cause the parameters are bad documented because theay change so often does not mean that parameter tuning is a bad thing in itself. I am used to increase freepages on my routers and i know that this is robust and i know that i am right with it.. and now average will kill of my atomic buffers while updatedb is running on those servers. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Evan Jeffrey wrote: > > > > 1. The inactive_target is 1 second worth of allocations, minus > > >the amount of frees in 1 second, averaged over a minute > > > > So it cannot take load bursts. That's ok for a default, but for special loads > > it would be good if there was a way for the administrator to overwrite that, > > similar to the old freepages. > > How about taking a decaying average (loadavg style) of the peak > allocation-free rate on a minute-by-minute basis. Then make the > number of seconds at that rate to use as the inactive_target a tunable > parameter. That way, a user could, if necessary, tune based on their > expected type of load (length of load bursts), and the alg. would tune > to the load level (height of those bursts). For a consistent load, > peak rate ~= avg. rate, and this decays to the current behavior, > except that the "1 second of allocations" is tunable. If we take the load avg analogy a bit further, we should be able to spot trends, at least to a limited extent: if the short term allocation rate is higher than the long term, there's an increasing trend, so we should probably try to keep more. Tracking something like the last minute - as presently - but divided into "last 30 seconds" and "previous 30 seconds" would probably help here; take the first minus the second (rate of "acceleration") and add to the first, and divide by 30. Use 32 for speed, perhaps, making it: ((a << 1) - b) >> 5 Should be an easy enough change, and a slightly better metric than just a simple average? > I haven't actually looked at the code, so I don't know how easy/hard > this is to implement, and while it does reintroduce a tuning > parameter, it should be needed less often, and has a much more > user-meaningful value (burst length) than # of free pages to keep > handy, which depends on the code, and could change between versions. With a reasonable "guess" based on recent history, we should be able to keep enough around to handle most circumstances. James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
In article [EMAIL PROTECTED] you wrote: How about taking a decaying average (loadavg style) of the peak allocation-free why? I think it is not a bad thing if you have some kind of setting like "irq heavy system" - "applicaion heavy system" even in NT you hve this slider. The current problem we have with linux that it is hard to tune cause the parameters are bad documented because theay change so often does not mean that parameter tuning is a bad thing in itself. I am used to increase freepages on my routers and i know that this is robust and i know that i am right with it.. and now average will kill of my atomic buffers while updatedb is running on those servers. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
> > 1. The inactive_target is 1 second worth of allocations, minus > >the amount of frees in 1 second, averaged over a minute > > So it cannot take load bursts. That's ok for a default, but for special loads > it would be good if there was a way for the administrator to overwrite that, > similar to the old freepages. How about taking a decaying average (loadavg style) of the peak allocation-free rate on a minute-by-minute basis. Then make the number of seconds at that rate to use as the inactive_target a tunable parameter. That way, a user could, if necessary, tune based on their expected type of load (length of load bursts), and the alg. would tune to the load level (height of those bursts). For a consistent load, peak rate ~= avg. rate, and this decays to the current behavior, except that the "1 second of allocations" is tunable. I haven't actually looked at the code, so I don't know how easy/hard this is to implement, and while it does reintroduce a tuning parameter, it should be needed less often, and has a much more user-meaningful value (burst length) than # of free pages to keep handy, which depends on the code, and could change between versions. Evan --- Fear is the mind killer. -- Frank Herbert, "Dune" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, Sep 17, 2000 at 03:53:47PM -0300, Rik van Riel wrote: > On Sun, 17 Sep 2000, Andi Kleen wrote: > > On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: > > > > 1. The inactive_target is 1 second worth of allocations, minus > > >the amount of frees in 1 second, averaged over a minute > > > > So it cannot take load bursts. That's ok for a default, but for > > special loads it would be good if there was a way for the > > administrator to overwrite that, similar to the old freepages. > > OK, lets see if we can come up with some nice (self-tuning?) > idea for this at Linux Kongress ;) I don't like self tuning algorithms for this case, because they tend to cause a disruption on the first spike (e.g. causing lots of packets dropped first until the VM can adapt). When the admin says "I don't care if 10MB are wasted, I want it this way" explicitely he should get his will. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Andi Kleen wrote: > On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: > > 1. The inactive_target is 1 second worth of allocations, minus > >the amount of frees in 1 second, averaged over a minute > > So it cannot take load bursts. That's ok for a default, but for > special loads it would be good if there was a way for the > administrator to overwrite that, similar to the old freepages. OK, lets see if we can come up with some nice (self-tuning?) idea for this at Linux Kongress ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: > On Sun, 17 Sep 2000, Andi Kleen wrote: > > On Sun, Sep 17, 2000 at 02:35:42PM -0300, Rik van Riel wrote: > > > Also, the fact that the new VM keeps a list of directly > > > reclaimable inactive pages around that varies according > > > to the amount of VM activity should make tweaking this > > > value no longer needed... > > > > So there is no way to force the VM to keep lots of pages around > > for interrupt intensive load (like gigabit networking?) Is > > there a way to enforce that the inactive list is always well > > filled ? > > 1. The inactive_target is 1 second worth of allocations, minus >the amount of frees in 1 second, averaged over a minute So it cannot take load bursts. That's ok for a default, but for special loads it would be good if there was a way for the administrator to overwrite that, similar to the old freepages. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, Sep 17, 2000 at 02:35:42PM -0300, Rik van Riel wrote: > Also, the fact that the new VM keeps a list of directly > reclaimable inactive pages around that varies according > to the amount of VM activity should make tweaking this > value no longer needed... So there is no way to force the VM to keep lots of pages around for interrupt intensive load (like gigabit networking?) Is there a way to enforce that the inactive list is always well filled ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Patrick Mau wrote: > I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess > these days ...) and noticed that /proc/sys/vm/freepages is no > longer writable: > > [root@oscar] ll /proc/sys/vm/freepages > -r--r--r--1 root root0 Sep 17 02:25 /proc/sys/vm/freepages > > If this was intentional, why has it changed ? It was intentional. Writing to this file hasn't worked well since 2.3.50 or so, when the zoned VM was merged. Also, the fact that the new VM keeps a list of directly reclaimable inactive pages around that varies according to the amount of VM activity should make tweaking this value no longer needed... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Patrick Mau wrote: I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess these days ...) and noticed that /proc/sys/vm/freepages is no longer writable: [root@oscar] ll /proc/sys/vm/freepages -r--r--r--1 root root0 Sep 17 02:25 /proc/sys/vm/freepages If this was intentional, why has it changed ? It was intentional. Writing to this file hasn't worked well since 2.3.50 or so, when the zoned VM was merged. Also, the fact that the new VM keeps a list of directly reclaimable inactive pages around that varies according to the amount of VM activity should make tweaking this value no longer needed... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, Sep 17, 2000 at 02:35:42PM -0300, Rik van Riel wrote: Also, the fact that the new VM keeps a list of directly reclaimable inactive pages around that varies according to the amount of VM activity should make tweaking this value no longer needed... So there is no way to force the VM to keep lots of pages around for interrupt intensive load (like gigabit networking?) Is there a way to enforce that the inactive list is always well filled ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: On Sun, 17 Sep 2000, Andi Kleen wrote: On Sun, Sep 17, 2000 at 02:35:42PM -0300, Rik van Riel wrote: Also, the fact that the new VM keeps a list of directly reclaimable inactive pages around that varies according to the amount of VM activity should make tweaking this value no longer needed... So there is no way to force the VM to keep lots of pages around for interrupt intensive load (like gigabit networking?) Is there a way to enforce that the inactive list is always well filled ? 1. The inactive_target is 1 second worth of allocations, minus the amount of frees in 1 second, averaged over a minute So it cannot take load bursts. That's ok for a default, but for special loads it would be good if there was a way for the administrator to overwrite that, similar to the old freepages. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Andi Kleen wrote: On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: 1. The inactive_target is 1 second worth of allocations, minus the amount of frees in 1 second, averaged over a minute So it cannot take load bursts. That's ok for a default, but for special loads it would be good if there was a way for the administrator to overwrite that, similar to the old freepages. OK, lets see if we can come up with some nice (self-tuning?) idea for this at Linux Kongress ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
On Sun, Sep 17, 2000 at 03:53:47PM -0300, Rik van Riel wrote: On Sun, 17 Sep 2000, Andi Kleen wrote: On Sun, Sep 17, 2000 at 03:09:52PM -0300, Rik van Riel wrote: 1. The inactive_target is 1 second worth of allocations, minus the amount of frees in 1 second, averaged over a minute So it cannot take load bursts. That's ok for a default, but for special loads it would be good if there was a way for the administrator to overwrite that, similar to the old freepages. OK, lets see if we can come up with some nice (self-tuning?) idea for this at Linux Kongress ;) I don't like self tuning algorithms for this case, because they tend to cause a disruption on the first spike (e.g. causing lots of packets dropped first until the VM can adapt). When the admin says "I don't care if 10MB are wasted, I want it this way" explicitely he should get his will. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/vm/freepages not writable.
> I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess > these days ...) and noticed that /proc/sys/vm/freepages is no > longer writable: > If this was intentional, why has it changed ? New VM in test9-pre1. Changing this field is no longer relevant to the restructured code. Dave. -- | Dave Jones <[EMAIL PROTECTED]> | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc/sys/vm/freepages not writable.
Dear kernel-hackers, I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess these days ...) and noticed that /proc/sys/vm/freepages is no longer writable: [root@oscar] ll /proc/sys/vm/freepages -r--r--r--1 root root0 Sep 17 02:25 /proc/sys/vm/freepages If this was intentional, why has it changed ? thanks, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/proc/sys/vm/freepages not writable.
Dear kernel-hackers, I compiled kernel 2.4.0test9-pre1 (kernel names are a real mess these days ...) and noticed that /proc/sys/vm/freepages is no longer writable: [root@oscar] ll /proc/sys/vm/freepages -r--r--r--1 root root0 Sep 17 02:25 /proc/sys/vm/freepages If this was intentional, why has it changed ? thanks, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
