From: Andrew Morton <akpm@linux-foundation.org>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: splice: move balance_dirty_pages_ratelimited() outside of splice actor
Date: Tue, 12 Jun 2007 09:02:30 -0700 [thread overview]
Message-ID: <20070612090230.19ab939c.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070612124449.GD18832@kernel.dk>
On Tue, 12 Jun 2007 14:44:50 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> On Tue, Jun 12 2007, Peter Zijlstra wrote:
> > On Tue, 2007-06-12 at 14:10 +0200, Jens Axboe wrote:
> > > On Tue, Jun 12 2007, Peter Zijlstra wrote:
> > > > On Tue, 2007-06-12 at 13:31 +0200, Jens Axboe wrote:
> > > >
> > > > > Would you prefer this change, then? I'd prefer keeping the current code,
> > > > > unless it's absolutely critical that we call
> > > > > balance_dirty_pages_ratelimited() for each and every page instead of eg
> > > > > every 16 pages here.
> > > >
> > > > For that we should call:
> > > > balance_dirty_pages_ratelimited_nr(mapping, nr);
> > > >
> > > > Which is ok, for small nr.
> > >
> > > OK, then this should be better:
yup, the patch looks fine, thanks.
It will in practice be OK calling balance_dirty_pages() once per 16 pages
but one should try to be a good little kernel citizen and do the right
thing, I guess.
> > > diff --git a/fs/splice.c b/fs/splice.c
> > > index 25ec9c8..ed40967 100644
> > > --- a/fs/splice.c
> > > +++ b/fs/splice.c
> > > @@ -844,6 +883,9 @@ generic_file_splice_write_nolock(struct pipe_inode_info *pipe, struct file *out,
> > > sd.file = out;
> > > ret = __splice_from_pipe(pipe, &sd, pipe_to_file);
> > > if (ret > 0) {
> > > + unsigned long nr_pages;
> > > +
> > > + nr_pages = (ret + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
> >
> > perhaps?
> > nr_pages = DIV_ROUND_UP(ret, PAGE_CACHE_SIZE);
> >
> > not sure how horrid that turns out to be; you never know with gcc.
>
> Well, I think such macros are horribly ugly and that the original code
> is MUCH easier to read.
I think the macros are pretty foul too (perhaps we should migrate it to
"div_round_up()").
But we should migrate to them. Because once one has learned what a
particular helper like this does, the code becomes more readable, more
understandable and easier to verify correct behaviour. Whereas the
open-coded arithmetic is _always_ suspect and always needs to be checked
each time one's eye passes over it.
And then there's the ongoing pitter-patter of "convert to DIV_ROUND_UP"
patches in my inbox ;)
It's not, however, our biggest problem.
next prev parent reply other threads:[~2007-06-12 16:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200706112159.l5BLxF5x004043@hera.kernel.org>
2007-06-11 23:34 ` splice: move balance_dirty_pages_ratelimited() outside of splice actor Andrew Morton
2007-06-12 6:35 ` Jens Axboe
2007-06-12 11:20 ` Jens Axboe
2007-06-12 11:31 ` Jens Axboe
2007-06-12 12:06 ` Peter Zijlstra
2007-06-12 12:10 ` Jens Axboe
2007-06-12 12:16 ` Peter Zijlstra
2007-06-12 12:44 ` Jens Axboe
2007-06-12 16:02 ` Andrew Morton [this message]
2007-06-12 16:46 ` Andrew Morton
2007-06-12 17:32 ` Jens Axboe
2007-06-12 18:15 ` Jens Axboe
2007-06-12 18:43 ` Andrew Morton
2007-06-12 18:48 ` Jens Axboe
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=20070612090230.19ab939c.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
/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.