Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

On Thu, Oct 02 2008, Dave Chinner wrote:
On Thu, Oct 02, 2008 at 09:55:11AM +0200, Jens Axboe wrote:
On Thu, Oct 02 2008, Andi Kleen wrote:
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:

On Wed, 1 Oct 2008 20:00:34 -0700 Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:

Subject: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

You proposed this a while back and it didn't happen and I forget
why and the changelog doesn't mention any of that?

XFS tried this some time ago too.

I think the issue was that real user supplied RT applications don't want to
compete with a "pseudo RT" kjournald.

So it would really need a new priority class between RT and normal priority.

Good point. I think we should mark the IO as sync, and maintain the same
priority level. Any IO that ends up being waited on is sync by
definition, we just need to expand the coverage a bit.

That's what XFS has always done - mark the journal I/O as sync.
Still, once you load up the elevator, the sync I/O can still get
delayed for hundreds of milliseconds before dispatch, which was
why I started looking at boosting the priority of the log I/O.
It proved to be much more effective at getting the log I/O
dispatched than the existing "mark it sync" technique....

Sure, just marking it as sync is not a magic bullet. It'll be in the
first priority for that class, but it'll share bandwidth with other
processes. So if you have lots of IO going on, it can take hundreds of
miliseconds before being dispatched.

RT will always be faster, but mainly by virtue of there being no RT IO
in the first place. And of course preferential treatment is given to
this higher priority scheduling class.

The RT folk were happy with the idea of journal I/O using the
highest non-RT priority for the journal, but I never got around
to testing that out as I had a bunnch of other stuff to fix at
the time.

That's a good idea, just bump the priority a little bit. Arjan, did you
test that out? I'd suggest just trying prio level 0 and still using
best-effort scheduling. Probably still need the sync marking, would be
interesting to experiment with though.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority
    ... That's what XFS has always done - mark the journal I/O as sync. ... delayed for hundreds of milliseconds before dispatch, ... why I started looking at boosting the priority of the log I/O. ... It proved to be much more effective at getting the log I/O ...
    (Linux-Kernel)
  • Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority
    ... That's what XFS has always done - mark the journal I/O as sync. ... why I started looking at boosting the priority of the log I/O. ...
    (Linux-Kernel)
  • Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority
    ... So it would really need a new priority class between RT and normal priority. ... I think we should mark the IO as sync, ... That's what XFS has always done - mark the journal I/O as sync. ...
    (Linux-Kernel)
  • Re: Background thread with lower priority
    ... records and saves them to the local database. ... background sync takes about 20 seconds. ... Running it at a lower priority would allow the UI to get quantum before ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Tasks losing information between 2 PC syncs
    ... I'm using ActiveSync 4.2 and date/time/zone is consistent. ... The priority change is reflected on the attached device immediately, ... ActiveSync", as either 4.2 or 4.5beta might fit that description. ... I only sync Contacts, Tasks, Notes. ...
    (microsoft.public.pocketpc.activesync)
Loading