linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, ck@vds.kolivas.org
Subject: Re: [PATCH] mm: yield during swap prefetching
Date: Tue, 7 Mar 2006 17:11:34 -0800	[thread overview]
Message-ID: <20060307171134.59288092.akpm@osdl.org> (raw)
In-Reply-To: <200603081151.13942.kernel@kolivas.org>

Con Kolivas <kernel@kolivas.org> wrote:
>
> On Wed, 8 Mar 2006 11:05 am, Andrew Morton wrote:
> > Con Kolivas <kernel@kolivas.org> wrote:
> > > > yield() really sucks if there are a lot of runnable tasks.  And the
> > > > amount of CPU which that thread uses isn't likely to matter anyway.
> > > >
> > > > I think it'd be better to just not do this.  Perhaps alter the thread's
> > > > static priority instead?  Does the scheduler have a knob which can be
> > > > used to disable a tasks's dynamic priority boost heuristic?
> > >
> > > We do have SCHED_BATCH but even that doesn't really have the desired
> > > effect. I know how much yield sucks and I actually want it to suck as
> > > much as yield does.
> >
> > Why do you want that?
> >
> > If prefetch is doing its job then it will save the machine from a pile of
> > major faults in the near future.  The fact that the machine happens to be
> > running a number of busy tasks doesn't alter that.  It's _worth_ stealing a
> > few cycles from those tasks now to avoid lengthy D-state sleeps in the near
> > future?
> 
> The test case is the 3d (gaming) app that uses 100% cpu. It never sets delay 
> swap prefetch in any way so swap prefetching starts working. Once swap 
> prefetching starts reading it is mostly in uninterruptible sleep and always 
> wakes up on the active array ready for cpu, never expiring even with its 
> miniscule timeslice. The 3d app is always expiring and landing on the expired 
> array behind kprefetchd even though kprefetchd is nice 19. The practical 
> upshot of all this is that kprefetchd does a lot of prefetching with 3d 
> gaming going on, and no amount of priority fiddling stops it doing this. The 
> disk access is noticeable during 3d gaming unfortunately. Yielding regularly 
> means a heck of a lot less prefetching occurs and is no longer noticeable. 
> When idle, yield()ing doesn't seem to adversely affect the effectiveness of 
> the prefetching.
> 

but, but.  If prefetching is prefetching stuff which that game will soon
use then it'll be an aggregate improvement.  If prefetch is prefetching
stuff which that game _won't_ use then prefetch is busted.  Using yield()
to artificially cripple kprefetchd is a rather sad workaround isn't it?

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-03-08  1:11 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-07 23:13 Con Kolivas
2006-03-07 23:26 ` Andrew Morton
2006-03-07 23:32   ` Con Kolivas
2006-03-08  0:05     ` Andrew Morton
2006-03-08  0:51       ` Con Kolivas
2006-03-08  1:11         ` Andrew Morton [this message]
2006-03-08  1:12           ` Con Kolivas
2006-03-08  1:19             ` Con Kolivas
2006-03-08  1:23             ` Andrew Morton
2006-03-08  1:28               ` Con Kolivas
2006-03-08  2:08                 ` Lee Revell
2006-03-08  2:12                   ` Con Kolivas
2006-03-08  2:18                     ` Lee Revell
2006-03-08  2:22                       ` Con Kolivas
2006-03-08  2:27                         ` Lee Revell
2006-03-08  2:30                           ` Con Kolivas
2006-03-08  2:52                             ` [ck] " André Goddard Rosa
2006-03-08  3:03                               ` Lee Revell
2006-03-08  3:05                               ` Con Kolivas
2006-03-08 21:07                                 ` Zan Lynx
2006-03-08 23:00                                   ` Con Kolivas
2006-03-08 23:48                                     ` Zan Lynx
2006-03-09  0:07                                       ` Con Kolivas
2006-03-09  3:13                                         ` Zan Lynx
2006-03-09  4:08                                           ` Con Kolivas
2006-03-09  4:54                                             ` Lee Revell
2006-03-08  7:51                 ` Jan Knutar
2006-03-08  8:39                   ` Con Kolivas
2006-03-09  8:57             ` Helge Hafting
2006-03-09  9:08               ` Con Kolivas
2006-03-09 22:44                 ` Peter Williams
2006-03-10  9:01                   ` [ck] " Andreas Mohr
2006-03-10  9:11                     ` Con Kolivas
2006-03-10  0:58                 ` Peter Williams
2006-03-08 22:24       ` Pavel Machek
2006-03-09  2:22         ` Nick Piggin
2006-03-09  2:30           ` Con Kolivas
2006-03-09  2:57             ` Nick Piggin
2006-03-09  9:11               ` Con Kolivas
2006-03-08 13:36     ` [ck] " Con Kolivas
2006-03-17  9:06       ` Ingo Molnar
2006-03-08  8:48   ` Andreas Mohr
2006-03-08  8:52     ` Con Kolivas

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=20060307171134.59288092.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ck@vds.kolivas.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox