On Wed, 20 Sep 2000, Andrea Arcangeli wrote:
> On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote:
> > On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> > > On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> > > > what I wanted to do in the new VM, except that I didn't
> > > >
On Wed, 20 Sep 2000, Andrea Arcangeli wrote:
On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote:
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
what I wanted to do in the new VM, except that I didn't
see why we
On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote:
> On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> > On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> > > what I wanted to do in the new VM, except that I didn't
> > > see why we would want to restrict it to swap pages
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
> On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> > what I wanted to do in the new VM, except that I didn't
> > see why we would want to restrict it to swap pages only?
>
> You _must_ do that _only_ for the swap_cache, that's a
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
what I wanted to do in the new VM, except that I didn't
see why we would want to restrict it to swap pages only?
You _must_ do that _only_ for the swap_cache, that's a specific
On Wed, Sep 20, 2000 at 12:53:18PM -0300, Rik van Riel wrote:
On Tue, 19 Sep 2000, Andrea Arcangeli wrote:
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
what I wanted to do in the new VM, except that I didn't
see why we would want to restrict it to swap pages only?
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
> what I wanted to do in the new VM, except that I didn't
> see why we would want to restrict it to swap pages only?
You _must_ do that _only_ for the swap_cache, that's a specific issue of the
swap_cache during swapout (notenote: not
On Mon, 18 Sep 2000, Byron Stanoszek wrote:
> I've finally had a chance to test out the new VM patch on my 32mb system.
>
> It runs much, much better than the previous test8, and the
> pages->swap change is actually much smoother than I had expected
> it to be considering the recent talk about
Byron Stanoszek wrote:
>
> I've finally had a chance to test out the new VM patch on my 32mb system.
>
> It runs much, much better than the previous test8, and the pages->swap change
> is actually much smoother than I had expected it to be considering the recent
> talk about making it more
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> I don't know the internals of other OSes so I've no idea if that
> was a generic problem or not (guess why I started playing with
> linux: just to finally see the internals of an OS :) thus I
> don't know if this problem is generic or not.
Please
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
I don't know the internals of other OSes so I've no idea if that
was a generic problem or not (guess why I started playing with
linux: just to finally see the internals of an OS :) thus I
don't know if this problem is generic or not.
Please take
Byron Stanoszek wrote:
I've finally had a chance to test out the new VM patch on my 32mb system.
It runs much, much better than the previous test8, and the pages-swap change
is actually much smoother than I had expected it to be considering the recent
talk about making it more gradual.
On Tue, Sep 19, 2000 at 05:29:29AM -0300, Rik van Riel wrote:
what I wanted to do in the new VM, except that I didn't
see why we would want to restrict it to swap pages only?
You _must_ do that _only_ for the swap_cache, that's a specific issue of the
swap_cache during swapout (notenote: not
I've finally had a chance to test out the new VM patch on my 32mb system.
It runs much, much better than the previous test8, and the pages->swap change
is actually much smoother than I had expected it to be considering the recent
talk about making it more gradual. I'm against having the swap
I've finally had a chance to test out the new VM patch on my 32mb system.
It runs much, much better than the previous test8, and the pages-swap change
is actually much smoother than I had expected it to be considering the recent
talk about making it more gradual. I'm against having the swap more
On Sun, Sep 17, 2000 at 04:36:34PM -0300, Rik van Riel wrote:
> On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> > On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
> > > The new VM, as integrated in -test9-pre1, does the same thing,
> >
> > Thanks for giving me some credit for my
On Sun, Sep 17, 2000 at 03:42:08PM -0400, Byron Stanoszek wrote:
> Not to be a bother, but I would still like to see a value or at least someone
> tell me what calculations I would need to do with the values listed in
> /proc/meninfo in order to determine the number of pages actually in-use by
>
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
> > The new VM, as integrated in -test9-pre1, does the same thing,
>
> Thanks for giving me some credit for my ideas.
Your ideas? This is as much your idea as it is mine (which
it
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 03:42:08PM -0400, Byron Stanoszek wrote:
> > Not to be a bother, but I would still like to see a value or at least someone
> > tell me what calculations I would need to do with the values listed in
> > /proc/meninfo in order
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> Some of the fields recently added to /proc/meminfo are very dependent on the
> internal of the memory management of the kernel, I don't think it's good idea
> to make them part of the user<->kernel API because there are alteratvive
> algorithms that
On Sun, Sep 17, 2000 at 03:36:04PM -0300, Rik van Riel wrote:
> On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> > On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
> > > If you have a better idea for memory management, I'd
> > > like to hear it ;)
> >
> > You know
On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
> The new VM, as integrated in -test9-pre1, does the same thing,
Thanks for giving me some credit for my ideas.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Sun, Sep 17, 2000 at 05:37:13PM -0300, Rik van Riel wrote:
> Sysrq-M displays the info for my VM too, but you'll have to
> admit that it isn't as useful as vmstat ;)
I agree about that info. That's an information not really relevant to the
internal of the memory balancing algorithm, but it's
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
> > If you have a better idea for memory management, I'd
> > like to hear it ;)
>
> You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++
> under low memory scenario, right?
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
> > If you have a better idea for memory management, I'd
> > like to hear it ;)
>
> You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++
> under low memory scenario, right?
On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
> If you have a better idea for memory management, I'd
> like to hear it ;)
You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++ under low
memory scenario, right?
The only thing it can be a problem for an alternate VM if
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
> On Sun, Sep 17, 2000 at 12:11:40AM -0400, Albert D. Cahalan wrote:
> > Umm, OK. I suppose that BSD prints this stuff? If so,
> > somebody please send me an output sample and explanation
> > so that I know where to put this stuff.
>
> Some of the
On Sun, Sep 17, 2000 at 12:11:40AM -0400, Albert D. Cahalan wrote:
> Umm, OK. I suppose that BSD prints this stuff? If so,
> somebody please send me an output sample and explanation
> so that I know where to put this stuff.
Some of the fields recently added to /proc/meminfo are very dependent on
On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
If you have a better idea for memory management, I'd
like to hear it ;)
You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++ under low
memory scenario, right?
The only thing it can be a problem for an alternate VM if
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
If you have a better idea for memory management, I'd
like to hear it ;)
You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++
under low memory scenario, right?
You know
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
If you have a better idea for memory management, I'd
like to hear it ;)
You know 2.4.0-test1-ac22-class++ beaten 2.4.0-test1-ac22-riel++
under low memory scenario, right?
Btw, do
On Sun, Sep 17, 2000 at 05:37:13PM -0300, Rik van Riel wrote:
Sysrq-M displays the info for my VM too, but you'll have to
admit that it isn't as useful as vmstat ;)
I agree about that info. That's an information not really relevant to the
internal of the memory balancing algorithm, but it's
On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
The new VM, as integrated in -test9-pre1, does the same thing,
Thanks for giving me some credit for my ideas.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
Some of the fields recently added to /proc/meminfo are very dependent on the
internal of the memory management of the kernel, I don't think it's good idea
to make them part of the user-kernel API because there are alteratvive
algorithms that won't
On Sun, Sep 17, 2000 at 03:36:04PM -0300, Rik van Riel wrote:
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 17, 2000 at 02:33:48PM -0300, Rik van Riel wrote:
If you have a better idea for memory management, I'd
like to hear it ;)
You know 2.4.0-test1-ac22-class++ beaten
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 17, 2000 at 03:42:08PM -0400, Byron Stanoszek wrote:
Not to be a bother, but I would still like to see a value or at least someone
tell me what calculations I would need to do with the values listed in
/proc/meninfo in order to
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
On Sun, Sep 17, 2000 at 03:43:53PM -0300, Rik van Riel wrote:
The new VM, as integrated in -test9-pre1, does the same thing,
Thanks for giving me some credit for my ideas.
Your ideas? This is as much your idea as it is mine (which
it isn't).
On Sun, Sep 17, 2000 at 03:42:08PM -0400, Byron Stanoszek wrote:
Not to be a bother, but I would still like to see a value or at least someone
tell me what calculations I would need to do with the values listed in
/proc/meninfo in order to determine the number of pages actually in-use by
Rik van Riel writes:
> It would be better to put that in a userspace tool like
> vmstat.
>
> Oh, and now we're talking about vmstat, I guess that
> program also needs support for displaying the number
> of active/inactive_dirty/inactive_clean pages ... ;)
>
> (any volunteers?)
Umm, OK. I
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Byron Stanoszek wrote:
>
> > I'd like to be able to use that extra 16mb for process memory more than I would
> > for cache. When most of my programs get loaded up, it totals to around 24mb on
> > average, and medium-to-low disk
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Rik van Riel wrote:
>
> > MemFree: memory on the freelist, contains no data
> > Buffers: buffer cache memory
> > Cached: page cache memory
> >
> > Active: buffer or page cache memory which is in active
> >
On Sat, 16 Sep 2000, Rik van Riel wrote:
> MemFree: memory on the freelist, contains no data
> Buffers: buffer cache memory
> Cached: page cache memory
>
> Active: buffer or page cache memory which is in active
> use (that is, page->age > 0 or many
On Sat, 16 Sep 2000, Rik van Riel wrote:
> It would be better to put that in a userspace tool like
> vmstat.
Or modify 'free', which is what I was going to do. How would I find the number
of actual pages-in-use from those variables? I've tried adding and subtracting
several and can't seem to
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> Active pages increased to 18688kB, and we see some inact_clean.
> Is this normal as intended?
Yes. There are 2 things going on during that find.
1) find touches buffers all over the place, those
buffers will be added to the active list
2)
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> I'd like to be able to use that extra 16mb for process memory more than I would
> for cache. When most of my programs get loaded up, it totals to around 24mb on
> average, and medium-to-low disk access is used. I like the way it is now, where
> it
On Sat, 16 Sep 2000, Rik van Riel wrote:
> OTOH, maybe we want to do /some/ background swapping of
> sleeping tasks, to smooth out the VM a bit at the point
> where we start to run into the situation where we need
> to swap something out...
This is something like what the previous VM did, and
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> On Sat, 16 Sep 2000, Rik van Riel wrote:
> > On Sat, 16 Sep 2000, Dietmar Kling wrote:
> >
> > > i thought i add a report to the new VM in 2.4.0pre9
> > > When I tried to restart my work after 2 hours,
> > > the machine started swapping madly.
> >
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
> I think I might have a similar problem with 2.4.0-t8-vmpatch2, related to
> caching. Without the vmpatch, my standard system 'used' would be near 28mb
> actual in use, the rest cached or in buffers. When I tried vmpatch2, standard
> usage eventually
Trever Adams wrote:
> Rik van Riel wrote:
> > > I believe this is a tuning issue, so
> > > i do not complain :)
> >
> > Indeed. Now that the testing base for the VM patch
> > has increased so much, there are a few as-of-yet
> > untested workloads popping up that don't perform
> > very well.
On Sat, 16 Sep 2000, Rik van Riel wrote:
> On Sat, 16 Sep 2000, Dietmar Kling wrote:
>
> > i thought i add a report to the new VM in 2.4.0pre9
> >
> > My Machine has 256 MB of memory
> > I left it for two hours ( several Netscapes -Instances,
> > Mail and xmms running _nothing in swap_ )
> >
Rik van Riel wrote:
> > I believe this is a tuning issue, so
> > i do not complain :)
>
> Indeed. Now that the testing base for the VM patch
> has increased so much, there are a few as-of-yet
> untested workloads popping up that don't perform
> very well.
>
> I'm gathering details about those
On Sat, 16 Sep 2000, Dietmar Kling wrote:
> i thought i add a report to the new VM in 2.4.0pre9
>
> My Machine has 256 MB of memory
> I left it for two hours ( several Netscapes -Instances,
> Mail and xmms running _nothing in swap_ )
>
> When I tried to restart my work after 2 hours,
> the
hi,
i thought i add a report to the new VM in 2.4.0pre9
My Machine has 256 MB of memory
I left it for two hours ( several Netscapes -Instances,
Mail and xmms running _nothing in swap_ )
When I tried to restart my work after 2 hours,
the machine started swapping madly. I couldn't
run the
hi,
i thought i add a report to the new VM in 2.4.0pre9
My Machine has 256 MB of memory
I left it for two hours ( several Netscapes -Instances,
Mail and xmms running _nothing in swap_ )
When I tried to restart my work after 2 hours,
the machine started swapping madly. I couldn't
run the
Trever Adams wrote:
Rik van Riel wrote:
I believe this is a tuning issue, so
i do not complain :)
Indeed. Now that the testing base for the VM patch
has increased so much, there are a few as-of-yet
untested workloads popping up that don't perform
very well.
I'm gathering
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
I think I might have a similar problem with 2.4.0-t8-vmpatch2, related to
caching. Without the vmpatch, my standard system 'used' would be near 28mb
actual in use, the rest cached or in buffers. When I tried vmpatch2, standard
usage eventually got
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
On Sat, 16 Sep 2000, Rik van Riel wrote:
On Sat, 16 Sep 2000, Dietmar Kling wrote:
i thought i add a report to the new VM in 2.4.0pre9
When I tried to restart my work after 2 hours,
the machine started swapping madly.
Does this
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
I'd like to be able to use that extra 16mb for process memory more than I would
for cache. When most of my programs get loaded up, it totals to around 24mb on
average, and medium-to-low disk access is used. I like the way it is now, where
it won't
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
Active pages increased to 18688kB, and we see some inact_clean.
Is this normal as intended?
Yes. There are 2 things going on during that find.
1) find touches buffers all over the place, those
buffers will be added to the active list
2) kflushd
On Sat, 16 Sep 2000, Rik van Riel wrote:
It would be better to put that in a userspace tool like
vmstat.
Or modify 'free', which is what I was going to do. How would I find the number
of actual pages-in-use from those variables? I've tried adding and subtracting
several and can't seem to get
On Sat, 16 Sep 2000, Rik van Riel wrote:
MemFree: memory on the freelist, contains no data
Buffers: buffer cache memory
Cached: page cache memory
Active: buffer or page cache memory which is in active
use (that is, page-age 0 or many references)
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
On Sat, 16 Sep 2000, Rik van Riel wrote:
MemFree: memory on the freelist, contains no data
Buffers: buffer cache memory
Cached: page cache memory
Active: buffer or page cache memory which is in active
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
On Sat, 16 Sep 2000, Byron Stanoszek wrote:
I'd like to be able to use that extra 16mb for process memory more than I would
for cache. When most of my programs get loaded up, it totals to around 24mb on
average, and medium-to-low disk access is
Rik van Riel writes:
It would be better to put that in a userspace tool like
vmstat.
Oh, and now we're talking about vmstat, I guess that
program also needs support for displaying the number
of active/inactive_dirty/inactive_clean pages ... ;)
(any volunteers?)
Umm, OK. I suppose that
64 matches
Mail list logo
