From: Zlatko Calusic <zlatko@iskon.hr>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm-cleanup-1 (2.4.0)
Date: 07 Jan 2001 23:20:21 +0100 [thread overview]
Message-ID: <877l4757iy.fsf@atlas.iskon.hr> (raw)
In-Reply-To: <Pine.LNX.4.21.0101071912570.21675-100000@duckman.distro.conectiva>
In-Reply-To: Rik van Riel's message of "Sun, 7 Jan 2001 19:16:47 -0200 (BRDT)"
Rik van Riel <riel@conectiva.com.br> writes:
> On 7 Jan 2001, Zlatko Calusic wrote:
>
> > The following patch cleans up some obsolete structures from the
> > mm & proc code.
> >
> > Beside that it also fixes what I think is a bug:
> >
> > if ((rw == WRITE) && atomic_read(&nr_async_pages) >
> > pager_daemon.swap_cluster * (1 << page_cluster))
> >
> > In that (swapout logic) it effectively says swap out 512KB at
> > once (at least on my memory configuration). I think that is a
> > little too much.
>
> Since we submit a whole cluster of (1 << page_cluster)
> size at once, your change would mean that the VM can
> only do one IO at a time...
>
> Have you actually measured your changes or is it just
> a gut feeling that the current default is too much?
>
Well, to be honest I didn't find any change after the modification. :)
But, anyway, Marcelo explained to me what's going on and I have
already agreed there is no need to change that. Instead I'll modify my
patch to introduce new /proc entry with meaningful name:
max_async_pages.
> (I can agree with 1/2 MB being a bit much, but doing
> just one IO at a time is probably wrong too...)
>
I can only add that I share your opinion. :)
>
> The cleanup part of your patch is nice. I think that
> one should be submitted as soon as the 2.4 bugfix
> period is over ...
>
Right.
> (and yes, I'm not submitting any of my own trivial
> patches either unless they're REALLY needed, lets make
> sure Linus has enough time to focus on the real bugfixes)
>
I'll check your new patch as soon as I have investigated few more
things and got a little more acquainted with the mm code in the
2.4.0. It's a pity I found some free time this late, but then again I
see myself much more involved with the mm code in the future. It's
just that I'll need some help in the start thus so much questions on
the lists. :)
--
Zlatko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
WARNING: multiple messages have this Message-ID (diff)
From: Zlatko Calusic <zlatko@iskon.hr>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm-cleanup-1 (2.4.0)
Date: 07 Jan 2001 23:20:21 +0100 [thread overview]
Message-ID: <877l4757iy.fsf@atlas.iskon.hr> (raw)
In-Reply-To: Rik van Riel's message of "Sun, 7 Jan 2001 19:16:47 -0200 (BRDT)"
Rik van Riel <riel@conectiva.com.br> writes:
> On 7 Jan 2001, Zlatko Calusic wrote:
>
> > The following patch cleans up some obsolete structures from the
> > mm & proc code.
> >
> > Beside that it also fixes what I think is a bug:
> >
> > if ((rw == WRITE) && atomic_read(&nr_async_pages) >
> > pager_daemon.swap_cluster * (1 << page_cluster))
> >
> > In that (swapout logic) it effectively says swap out 512KB at
> > once (at least on my memory configuration). I think that is a
> > little too much.
>
> Since we submit a whole cluster of (1 << page_cluster)
> size at once, your change would mean that the VM can
> only do one IO at a time...
>
> Have you actually measured your changes or is it just
> a gut feeling that the current default is too much?
>
Well, to be honest I didn't find any change after the modification. :)
But, anyway, Marcelo explained to me what's going on and I have
already agreed there is no need to change that. Instead I'll modify my
patch to introduce new /proc entry with meaningful name:
max_async_pages.
> (I can agree with 1/2 MB being a bit much, but doing
> just one IO at a time is probably wrong too...)
>
I can only add that I share your opinion. :)
>
> The cleanup part of your patch is nice. I think that
> one should be submitted as soon as the 2.4 bugfix
> period is over ...
>
Right.
> (and yes, I'm not submitting any of my own trivial
> patches either unless they're REALLY needed, lets make
> sure Linus has enough time to focus on the real bugfixes)
>
I'll check your new patch as soon as I have investigated few more
things and got a little more acquainted with the mm code in the
2.4.0. It's a pity I found some free time this late, but then again I
see myself much more involved with the mm code in the future. It's
just that I'll need some help in the start thus so much questions on
the lists. :)
--
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-01-07 22:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-07 20:36 [patch] mm-cleanup-1 (2.4.0) Zlatko Calusic
2001-01-07 20:36 ` Zlatko Calusic
2001-01-07 19:07 ` Marcelo Tosatti
2001-01-07 19:07 ` Marcelo Tosatti
2001-01-07 21:11 ` Zlatko Calusic
2001-01-07 21:11 ` Zlatko Calusic
2001-01-07 21:18 ` Rik van Riel
2001-01-07 21:18 ` Rik van Riel
2001-01-07 22:23 ` Zlatko Calusic
2001-01-07 22:23 ` Zlatko Calusic
2001-01-07 21:21 ` davej
2001-01-07 21:21 ` davej
2001-01-07 21:16 ` Rik van Riel
2001-01-07 21:16 ` Rik van Riel
2001-01-07 22:20 ` Zlatko Calusic [this message]
2001-01-07 22:20 ` Zlatko Calusic
2001-01-09 0:59 ` [patch] mm-cleanup-2 (2.4.0) Zlatko Calusic
2001-01-09 0:59 ` Zlatko Calusic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877l4757iy.fsf@atlas.iskon.hr \
--to=zlatko@iskon.hr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.