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
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
> > > >
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 probl
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 wa
> > 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,
> sim
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
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
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
> > >
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 lon
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
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/
> 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.
-
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 i
13 matches
Mail list logo