mm: yield during swap prefetching

Swap prefetching doesn't use very much cpu but spends a lot of time waiting on disk in uninterruptible sleep. This means it won't get preempted often even at a low nice level since it is seen as sleeping most of the time. We want to minimise its cpu impact so yield where possible.

Signed-off-by Con Kolivas <[email protected]>

---
 mm/swap_prefetch.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.15-ck5/mm/swap_prefetch.c
===================================================================

Quoted 19 lines · Con Kolivas

Swap prefetching doesn't use very much cpu but spends a lot of time waiting on disk in uninterruptible sleep. This means it won't get preempted often even at a low nice level since it is seen as sleeping most of the time. We want to minimise its cpu impact so yield where possible.

Signed-off-by Con Kolivas <[email protected]>

---
 mm/swap_prefetch.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.15-ck5/mm/swap_prefetch.c
===================================================================

mm/swap_prefetch.c +1 -0

@@ -421,6 +421,7 @@ static enum trickle_return trickle_swap(
 
 		if (trickle_swap_cache_async(swp_entry, node) == TRICKLE_DELAY)
 			break;
+		yield();
 	}
 

mm/swap_prefetch.c static enum trickle_return trickle_swap( · line 427

Quoted 1 line

mm/swap_prefetch.c +0 -0

 	if (sp_stat.prefetched_pages) {

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?

Quoted 7 lines

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.

Quoted 10 lines · Con Kolivas

Quoted 6 lines

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?

Quoted 12 lines · Andrew Morton

Quoted 10 lines · Con Kolivas

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 22 lines · Con Kolivas

Quoted 13 lines · Andrew Morton

Quoted 11 lines · Con Kolivas

Quoted 7 lines

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.

Quoted 7 lines

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?

Quoted 12 lines

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?

Quoted 37 lines · Andrew Morton

Quoted 35 lines · Con Kolivas

Quoted 14 lines · Andrew Morton

Quoted 4 lines · Con Kolivas

Quoted 4 lines

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

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?

It's not the stuff that it prefetches that's the problem; it's the disk access.

Quoted 5 lines

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?

It's not the stuff that it prefetches that's the problem; it's the disk access.

Quoted 6 lines · Con Kolivas

Quoted 5 lines

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?

Quoted 2 lines

It's not the stuff that it prefetches that's the problem; it's the disk access.

But the prefetch code tries to avoid prefetching when the disk is otherwise busy (or it should - we discussed that a bit a while ago).

Sorry, I'm not trying to be awkward here - I think that nobbling prefetch when there's a lot of CPU activity is just the wrong thing to do and it'll harm other workloads.

I can't distinguish between when cpu activity is important (game) and when it is not (compile), and assuming worst case scenario and not doing any swap prefetching is my intent. I could add cpu accounting to prefetch_suitable() instead, but that gets rather messy and yielding achieves the same endpoint.

Quoted 5 lines · Con Kolivas

I can't distinguish between when cpu activity is important (game) and when it is not (compile), and assuming worst case scenario and not doing any swap prefetching is my intent. I could add cpu accounting to prefetch_suitable() instead, but that gets rather messy and yielding achieves the same endpoint.

Shouldn't the game be running with RT priority or at least at a low nice value?

Quoted 7 lines · Lee Revell

Quoted 5 lines · Con Kolivas

I can't distinguish between when cpu activity is important (game) and when it is not (compile), and assuming worst case scenario and not doing any swap prefetching is my intent. I could add cpu accounting to prefetch_suitable() instead, but that gets rather messy and yielding achieves the same endpoint.

Quoted 2 lines

Shouldn't the game be running with RT priority or at least at a low nice value?

No way. Games run nice 0 SCHED_NORMAL.

Quoted 8 lines · Con Kolivas

Quoted 7 lines · Lee Revell

Quoted 5 lines · Con Kolivas

I can't distinguish between when cpu activity is important (game) and when it is not (compile), and assuming worst case scenario and not doing any swap prefetching is my intent. I could add cpu accounting to prefetch_suitable() instead, but that gets rather messy and yielding achieves the same endpoint.

Quoted 4 lines

Quoted 2 lines

Shouldn't the game be running with RT priority or at least at a low nice value?

No way. Games run nice 0 SCHED_NORMAL.

Maybe this is a stupid/OT question (answer off list if you think so) but why not? Isn't that the standard way of telling the scheduler that you have a realtime constraint? It's how pro audio stuff works which I would think has similar RT requirements.

How is the scheduler supposed to know to penalize a kernel compile taking 100% CPU but not a game using 100% CPU?

Quoted 2 lines

How is the scheduler supposed to know to penalize a kernel compile taking 100% CPU but not a game using 100% CPU?

Because being a serious desktop operating system that we are (bwahahahaha) means the user should not have special privileges to run something as simple as a game. Games should not need special scheduling classes. We can always use 'nice' for a compile though. Real time audio is a completely different world to this.

Quoted 8 lines · Con Kolivas

Quoted 2 lines

How is the scheduler supposed to know to penalize a kernel compile taking 100% CPU but not a game using 100% CPU?

Because being a serious desktop operating system that we are (bwahahahaha) means the user should not have special privileges to run something as simple as a game. Games should not need special scheduling classes. We can always use 'nice' for a compile though. Real time audio is a completely different world to this.

Actually recent distros like the upcoming Ubuntu Dapper support the new RLIMIT_NICE and RLIMIT_RTPRIO so this would Just Work without any special privileges (well, not root anyway - you'd have to put the user in the right group and add one line to /etc/security/limits.conf).

I think OSX also uses special scheduling classes for stuff with RT constraints.

The only barrier I see is that games aren't specifically written to take advantage of RT scheduling because historically it's only been available to root.

Quoted 5 lines

Quoted 5 lines

Because being a serious desktop operating system that we are (bwahahahaha) means the user should not have special privileges to run something as simple as a game. Games should not need special scheduling classes. We can always use 'nice' for a compile though. Real time audio is a completely different world to this.

Well as I said in my previous reply, games should _not_ need special scheduling classes. They are not written in a real time smart way and they do not have any realtime constraints or requirements.

Sorry Con, but I have to disagree with you on this.

Games are very complex software, involving heavy use of hardware resources
and they also have a lot of time constraints. So, I think they should use RT priorities
if it is necessary to get the resources needed in time.

[...]

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Because being a serious desktop operating system that we are (bwahahahaha) means the user should not have special privileges to run something as simple as a game. Games should not need special scheduling classes. We can always use 'nice' for a compile though. Real time audio is a completely different world to this.

[...]

Quoted 3 lines

Well as I said in my previous reply, games should _not_ need special scheduling classes. They are not written in a real time smart way and they do not have any realtime constraints or requirements.

Sorry Con, but I have to disagree with you on this.

Games are very complex software, involving heavy use of hardware resources and they also have a lot of time constraints. So, I think they should use RT priorities
if it is necessary to get the resources needed in time.

Quoted 11 lines · André Goddard Rosa

[...]

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Because being a serious desktop operating system that we are (bwahahahaha) means the user should not have special privileges to run something as simple as a game. Games should not need special scheduling classes. We can always use 'nice' for a compile though. Real time audio is a completely different world to this.

[...]

Quoted 3 lines

Well as I said in my previous reply, games should _not_ need special scheduling classes. They are not written in a real time smart way and they do not have any realtime constraints or requirements.

Quoted 6 lines

Sorry Con, but I have to disagree with you on this.

Games are very complex software, involving heavy use of hardware resources and they also have a lot of time constraints. So, I think they should use RT priorities
if it is necessary to get the resources needed in time.

Excellent, I've opened the can of worms.

Yes, games are a in incredibly complex beast.

No they shouldn't need real time scheduling to work well if they are coded properly. However, witness the fact that most of our games are windows ports, therefore being lower quality than the original. Witness also the fact that at last with dual core support, lots and lots (but not all) of windows games on _windows_ are having scheduling trouble and jerky playback, forcing them to crappily force binding to one cpu.

Quoted 22 lines · Con Kolivas

Quoted 11 lines · André Goddard Rosa

[...]

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Because being a serious desktop operating system that we are (bwahahahaha) means the user should not have special privileges to run something as simple as a game. Games should not need special scheduling classes. We can always use 'nice' for a compile though. Real time audio is a completely different world to this.

[...]

Quoted 3 lines

Well as I said in my previous reply, games should _not_ need special scheduling classes. They are not written in a real time smart way and they do not have any realtime constraints or requirements.

Quoted 6 lines

Sorry Con, but I have to disagree with you on this.

Games are very complex software, involving heavy use of hardware resources and they also have a lot of time constraints. So, I think they should use RT priorities
if it is necessary to get the resources needed in time.

Excellent, I've opened the can of worms.

Quoted 8 lines

Yes, games are a in incredibly complex beast.

No they shouldn't need real time scheduling to work well if they are coded properly. However, witness the fact that most of our games are windows ports, therefore being lower quality than the original. Witness also the fact that at last with dual core support, lots and lots (but not all) of windows games on _windows_ are having scheduling trouble and jerky playback, forcing them to crappily force binding to one cpu.

[snip]

Games where you notice frame-rate chop because the *disk system* is using too much CPU are perfect examples of applications that should be using real-time.

Multiple CPU cores and multithreading in games is another perfect example of programming that *needs* predictable real-time thread priorities. There is no other way to guarantee that physics processing takes priority over graphics updates or AI, once each task becomes separated from a monolithic main loop and spread over several CPU cores.

Because games often *are* badly written, a user-friendly Linux gaming system does need a high-priority real-time task watching for a special keystroke, like C-A-Del for example, so that it can kill the other real-time tasks and return to the UI shell.

Games and real-time go together like they were made for each other.

Zan Lynx writes:

Quoted 1 line

Games and real-time go together like they were made for each other.

I guess every single well working windows game since the dawn of time is some sort of anomaly then.

Quoted 1 line · Con Kolivas

Zan Lynx writes:

[snip]

Quoted 3 lines

Quoted 1 line

Games and real-time go together like they were made for each other.

I guess every single well working windows game since the dawn of time is some sort of anomaly then.

Yes, those Windows games are anomalies that rely on the OS scheduling them AS IF they were real-time, but without actually claiming that priority.

Because these games just assume they own the whole system and aren't explicitly telling the OS about their real-time requirements, the OS has to guess instead and can get it wrong, especially when hardware capabilities advance in ways that force changes to the task scheduler (multi-core, hyper-threading). And you said it yourself, many old games don't work well on dual-core systems.

I think your effort to improve the guessing is a good idea, and thanks.

Just don't dismiss the idea that games do have real-time requirements and if they did things correctly, games would explicitly specify those requirements.

Games worked on windows for a decade on single core without real time scheduling because that's what they were written for.

Now that games are written for windows with dual core they work well - again
without real time scheduling.

Why should a port of these games to linux require real time?

Quoted 6 lines · Con Kolivas

Games worked on windows for a decade on single core without real time scheduling because that's what they were written for.

Now that games are written for windows with dual core they work well - again without real time scheduling.

Why should a port of these games to linux require real time?

That isn't what I said. I said nothing about *requiring* anything, only about how to do it better.

Here is what Con said that I was disagreeing with. All the rest was to justify my disagreement.

Con said, "... games should _not_ need special scheduling classes. They are not written in a real time smart way and they do not have any realtime constraints or requirements."

And he said later, "No they shouldn't need real time scheduling to work well if they are coded properly."

Here is a list of simple statements of what I am saying:
Games do have real-time requirements.
The OS guessing about real-time priorities will sometimes get it wrong. Guessing task priority is worse than being told and knowing for sure. Games should, in an ideal world, be using real-time OS scheduling. Games would work better using real-time OS scheduling.

Quoted 5 lines

Games do have real-time requirements.
The OS guessing about real-time priorities will sometimes get it wrong. Guessing task priority is worse than being told and knowing for sure. Games should, in an ideal world, be using real-time OS scheduling. Games would work better using real-time OS scheduling.

At the risk of being repetitive to the point of tiresome, my point is that there are no real time requirements in games. You're assuming that everything will be better if we assume that there are rt requirements and that we're simulating pseudo real time conditions currently. That's just not the case and never has been. That's why it has worked fine for so long.

Anything that does disk access delays prefetch fine. Things that only do heavy cpu do not delay prefetch. Anything reading from disk will be noticeable during 3d gaming.

Quoted 3 lines · Con Kolivas

Anything that does disk access delays prefetch fine. Things that only do heavy cpu do not delay prefetch. Anything reading from disk will be noticeable during 3d gaming.

What exactly makes the disk accesses noticeable? Is it because they steal time from the disk that the game otherwise would need, or do the disk accesses themselves consume noticeable amounts of CPU time?
Or, do bits of the game's executable drop from memory to make room for the new stuff being pulled in from memory, causing the game to halt while it waits for its pages to come back? On a related note, through advanced use of handwaving and guessing, this seems to be the thing that kills my destop experience (*buzzword alert*) most often. Checksumming a large file seems to be less of an impact than things that seek alot, like updatedb.

I remember playing vegastrike on my linux desktop machine few years ago, the game leaked so much memory that it filled my 2G swap rather often, unleashing OOM killer mayhem. I "solved" this by putting swap on floppy at lower priority than the 2G, and a 128M swap file as "backup" at even lower priority than the floppy. I didn't notice the swapping to harddrive, but when it started to swap to floppy, it made the game run a bit slower for a few seconds, plus the floppy light went on, and I knew I had 128M left to save my position and quit.

If I needed floppy to make disk access noticeable on my very low end machine... What are these new fancy things doing to make HD access noticeable?

Quoted 6 lines · Andrew Morton

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?

It's not the stuff that it prefetches that's the problem; it's the disk access.

Quoted 8 lines · Con Kolivas

Quoted 4 lines · Andrew Morton

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?

It's not the stuff that it prefetches that's the problem; it's the disk access.

Well, seems you have some sorry kind of disk driver then? An ide disk not using dma?

A low-cpu task that only abuses the disk shouldn't make an impact on a 3D game that hogs the cpu only. Unless the driver for your harddisk is faulty, using way more cpu than it need.

Use hdparm, check the basics:
unmaksirq=1, using_dma=1, multcount is some positive number, such as 8 or 16, readahead is some positive number. Also use hdparm -i and verify that the disk is using some nice udma mode. (too old for that, and it probably isn't worth optimizing this for...)

Also make sure the disk driver isn't sharing an irq with the 3D card.

Come to think of it, if your 3D game happens to saturate the pci bus for long times, then disk accesses might indeed be noticeable as they too need the bus. Check if going to a slower dma mode helps - this might free up the bus a bit.

Quoted 26 lines · Helge Hafting

Quoted 9 lines · Con Kolivas

Quoted 4 lines · Andrew Morton

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?

It's not the stuff that it prefetches that's the problem; it's the disk access.

Well, seems you have some sorry kind of disk driver then? An ide disk not using dma?

A low-cpu task that only abuses the disk shouldn't make an impact on a 3D game that hogs the cpu only. Unless the driver for your harddisk is faulty, using way more cpu than it need.

Use hdparm, check the basics:
unmaksirq=1, using_dma=1, multcount is some positive number, such as 8 or 16, readahead is some positive number. Also use hdparm -i and verify that the disk is using some nice udma mode. (too old for that, and it probably isn't worth optimizing this for...)

Quoted 7 lines

Also make sure the disk driver isn't sharing an irq with the 3D card.

Come to think of it, if your 3D game happens to saturate the pci bus for long times, then disk accesses might indeed be noticeable as they too need the bus. Check if going to a slower dma mode helps - this might free up the bus a bit.

Thanks for the hints.

However I actually wrote the swap prefetch code and this is all about changing its behaviour to make it do what I want. The problem is that nice 19 will give it up to 5% cpu in the presence of a nice 0 task when I really don't want swap prefetch doing anything.

Furthermore because it is constantly waking up from sleep (after disk activity) it is always given lower latency scheduling than a fully cpu bound nice 0 task - this is normally appropriate behaviour. Yielding regularly works around that issue.

Ideally taking into account cpu usage and only working below a certain cpu threshold may be the better mechanism and it does appear this would be more popular. It would not be hard to implement, but does add yet more code to an increasingly complex heuristic used to detect "idleness". I am seriously considering it.

I'm working on a patch to add soft and hard CPU rate caps to the scheduler and the soft caps may be useful for what you're trying to do.
They are a generalization of your SCHED_BATCH implementation in
staircase (which would have been better called SCHED_BACKGROUND :-)

IMHO) in that a task with a soft cap will only use more CPU than that cap if it (the cpu) would otherwise go unused. The main difference between this mechanism and staircase's SCHED_BATCH mechanism is that you can specify how much (as parts per thousand of a CPU) the task can use instead of just being background or not background. With the soft cap set to zero the effect would be essentially the same.

Hi,

Quoted 4 lines · Peter Williams

I'm working on a patch to add soft and hard CPU rate caps to the scheduler and the soft caps may be useful for what you're trying to do.
They are a generalization of your SCHED_BATCH implementation in
staircase (which would have been better called SCHED_BACKGROUND :-)

Which SCHED_BATCH? ;) I only know it as SCHED_IDLEPRIO, which, come to think of it, is a better name, I believe :-)
(renamed due to mainline introducing a *different* SCHED_BATCH mechanism)

Quoted 26 lines · Helge Hafting

Quoted 9 lines · Con Kolivas

Quoted 4 lines · Andrew Morton

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?

It's not the stuff that it prefetches that's the problem; it's the disk access.

Well, seems you have some sorry kind of disk driver then? An ide disk not using dma?

A low-cpu task that only abuses the disk shouldn't make an impact on a 3D game that hogs the cpu only. Unless the driver for your harddisk is faulty, using way more cpu than it need.

Use hdparm, check the basics:
unmaksirq=1, using_dma=1, multcount is some positive number, such as 8 or 16, readahead is some positive number. Also use hdparm -i and verify that the disk is using some nice udma mode. (too old for that, and it probably isn't worth optimizing this for...)

Quoted 7 lines

Also make sure the disk driver isn't sharing an irq with the 3D card.

Come to think of it, if your 3D game happens to saturate the pci bus for long times, then disk accesses might indeed be noticeable as they too need the bus. Check if going to a slower dma mode helps - this might free up the bus a bit.

Thanks for the hints.

However I actually wrote the swap prefetch code and this is all about changing its behaviour to make it do what I want. The problem is that nice 19 will give it up to 5% cpu in the presence of a nice 0 task when I really don't want swap prefetch doing anything.

Furthermore because it is constantly waking up from sleep (after disk activity) it is always given lower latency scheduling than a fully cpu bound nice 0 task - this is normally appropriate behaviour. Yielding regularly works around that issue.

Ideally taking into account cpu usage and only working below a certain cpu threshold may be the better mechanism and it does appear this would be more popular. It would not be hard to implement, but does add yet more code to an increasingly complex heuristic used to detect "idleness". I am seriously considering it.

Quoted 8 lines · Con Kolivas

Quoted 7 lines

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?

Quoted 3 lines

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

Quoted 2 lines · Andrew Morton

Why do you want that?

Quoted 3 lines

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

Or maybe not.... it is prefetch, it may prefetch wrongly, and you definitely want it doing nothing when system is loaded.... It only makes sense to prefetch when system is idle.

Quoted 9 lines · Pavel Machek

Quoted 4 lines · Andrew Morton

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

Or maybe not.... it is prefetch, it may prefetch wrongly, and you definitely want it doing nothing when system is loaded.... It only makes sense to prefetch when system is idle.

Right. Prefetching is obviously going to have a very low work/benefit, assuming your page reclaim is working properly, because a) it doesn't deal with file pages, and b) it is doing work to reclaim pages that have already been deemed to be the least important.

What it is good for is working around our interesting VM that apparently allows updatedb to swap everything out (although I haven't seen this problem myself), and artificial memory hogs. By moving work to times of low cost. No problem with the theory behind it.

So as much as a major fault costs in terms of performance, the tiny chance that prefetching will avoid it means even the CPU usage is questionable. Using sched_yield() seems like a hack though.

Quoted 5 lines · Nick Piggin

So as much as a major fault costs in terms of performance, the tiny chance that prefetching will avoid it means even the CPU usage is questionable. Using sched_yield() seems like a hack though.

Yeah it's a hack alright. Funny how at last I find a place where yield does exactly what I want and because we hate yield so much noone wants me to use it all.

Quoted 8 lines · Con Kolivas

Quoted 3 lines · Nick Piggin

So as much as a major fault costs in terms of performance, the tiny chance that prefetching will avoid it means even the CPU usage is questionable. Using sched_yield() seems like a hack though.

Yeah it's a hack alright. Funny how at last I find a place where yield does exactly what I want and because we hate yield so much noone wants me to use it all.

AFAIKS it is a hack for the same reason using it for locking is a hack, it's just that prefetch doesn't care if it doesn't get the CPU back for a while.

Given a yield implementation which does something completely different for SCHED_OTHER tasks, you code may find it doesn't work so well anymore. This is no different to the java folk using it with decent results for locking. Just because it happened to work OK for them at the time didn't mean it was the right thing to do.

I have always maintained that a SCHED_OTHER task calling sched_yield is basically a bug because it is utterly undefined behaviour.

But being an in-kernel user that "knows" the implementation sort of does the right thin, maybe you justify it that way.

Quoted 29 lines · Andrew Morton

Quoted 17 lines · Con Kolivas

Swap prefetching doesn't use very much cpu but spends a lot of time waiting on disk in uninterruptible sleep. This means it won't get preempted often even at a low nice level since it is seen as sleeping most of the time. We want to minimise its cpu impact so yield where possible.

Signed-off-by Con Kolivas <[email protected]>

---
 mm/swap_prefetch.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.15-ck5/mm/swap_prefetch.c
===================================================================
--- linux-2.6.15-ck5.orig/mm/swap_prefetch.c 2006-03-02
14:00:46.000000000 +1100 +++
linux-2.6.15-ck5/mm/swap_prefetch.c 2006-03-08 08:49:32.000000000 +1100

mm/swap_prefetch.c static enum trickle_return trickle_swap( · line 427

Quoted 7 lines

mm/swap_prefetch.c +1 -0

@@ -421,6 +421,7 @@ static enum trickle_return trickle_swap(
 
 		if (trickle_swap_cache_async(swp_entry, node) == TRICKLE_DELAY)
 			break;
+		yield();
 	}
 
 	if (sp_stat.prefetched_pages) {

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.

Quoted 3 lines

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.

Quoted 3 lines

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.

Thinking some more on this I wonder if SCHED_BATCH isn't a strong enough scheduling hint if it's not suitable for such an application. Ingo do you think we could make SCHED_BATCH tasks always wake up on the expired array?

yep, i think that's a good idea. In the worst case the starvation timeout should kick in.

Quoted 2 lines · Ingo Molnar

yep, i think that's a good idea. In the worst case the starvation timeout should kick in.

(I didn't want to hijack that thread ergo name change)

Speaking of the starvation timeout...

Problem solved. I now know why the starvation logic doesn't work. Wakeups. In the face of 10+ copies of httpd constantly waking up, it seems it just takes ages to get around to switching arrays.

With the (urp) patch below, I now get...

[root]:# time netstat|grep :81|wc -l
1648

real    0m27.735s
user    0m0.158s
sys     0m0.111s

[root]:# time netstat|grep :81|wc -l
1817

real    0m13.550s
user    0m0.121s
sys     0m0.186s

[root]:# time netstat|grep :81|wc -l
1641

real    0m17.022s
user    0m0.132s
sys     0m0.143s

[root]:#

<plug>
Even a desktop running with these settings is so interactive that I could play a game of Maelstrom (asteroids like thing) while doing a make -j30 in slow nfs mount and barely feel it. In a local filesystem, I could't feel it at all, so I added a thud 3, irman2 and a bonnie -s 2047 for good measure. Try that with stock :) </plug>

For those interested in these kind of things, here are the numbers for 2.6.16-rc6-mm2 with my [tarball] throttle patches applied...

[root]:# time netstat|grep :81|wc -l
1681

real    0m1.525s
user    0m0.141s
sys     0m0.136s

[root]:# time netstat|grep :81|wc -l
1491

real    0m0.356s
user    0m0.130s
sys     0m0.114s

[root]:# time netstat|grep :81|wc -l
1527

real    0m0.343s
user    0m0.129s
sys     0m0.114s

[root]:# time netstat|grep :81|wc -l
1568

real    0m0.512s
user    0m0.112s
sys     0m0.138s

...while running with the same apache loadavg of over 10, and tunables set to server mode (0,0).

<plug>
Even a desktop running with these settings is so interactive that I could play a game of Maelstrom (asteroids like thing) while doing a make -j30 in slow nfs mount and barely feel it. In a local filesystem, I could't feel it at all, so I added a thud 3, irman2 and a bonnie -s 2047 for good measure. Try that with stock :)
</plug>

Hi Mike,

Quoted 6 lines

real    0m0.512s
user    0m0.112s
sys     0m0.138s

...while running with the same apache loadavg of over 10, and tunables set to server mode (0,0).

Very good job !
I told Grant in a private email that I felt confident the problem would quickly be solved now that someone familiar with the scheduler could reliably reproduce it. Your numbers look excellent, I'm willing to test. Could you remind us what kernel and what patches we need to apply to try the same, please ?

Quoted 1 line · Willy Tarreau

Hi Mike,

Greetings!

Quoted 4 lines · Mike Galbraith

Quoted 1 line · Willy Tarreau

Hi Mike,

Greetings!

Thanks for the details,
I'll try to find some time to test your code quickly. If this fixes this long standing problem, we should definitely try to get it into 2.6.17 !

Quoted 5 lines · Willy Tarreau

Quoted 3 lines · Mike Galbraith

Quoted 1 line · Willy Tarreau

Hi Mike,

Quoted 5 lines

Quoted 1 line

Greetings!

Thanks for the details,
I'll try to find some time to test your code quickly. If this fixes this long standing problem, we should definitely try to get it into 2.6.17 !

the time window is quickly closing for that to happen though.

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Willy Tarreau

Quoted 3 lines · Mike Galbraith

Quoted 1 line · Willy Tarreau

Hi Mike,

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

Greetings!

Thanks for the details,
I'll try to find some time to test your code quickly. If this fixes this long standing problem, we should definitely try to get it into 2.6.17 !

the time window is quickly closing for that to happen though.

Ingo, Mike,

it's a great day :-)

Right now, I'm typing this mail from my notebook which has 8 instances of my exploit running in background. Previously, 4 of them were enough on this machine to create pauses of up to 31 seconds. Right now, I can type normally, and I simply can say that my exploit has no effect anymore ! It's just consuming CPU and nothing else. I also tried to write 0 to grace_g[12] and I find it even more responsive with 0 in those values. I've not had time to do more extensive tests, but I can assure you that the problem is clearly solved for me. I'd like Grant to test ssh on his firewall with it too.

great work by Mike! One detail: i'd like there to be just one default throttling value, i.e. no grace_g tunables [so that we have just one default scheduler behavior]. Is the default grace_g[12] setting good enough for your workload?

Quoted 4 lines · Ingo Molnar

great work by Mike! One detail: i'd like there to be just one default throttling value, i.e. no grace_g tunables [so that we have just one default scheduler behavior]. Is the default grace_g[12] setting good enough for your workload?

I agree. If anything is required, a simple on/off tunable makes much more sense. Much like I suggested ages ago with an "interactive" switch which was rather unpopular when I first suggested it.

Quoted 9 lines · Con Kolivas

Quoted 4 lines · Ingo Molnar

great work by Mike! One detail: i'd like there to be just one default throttling value, i.e. no grace_g tunables [so that we have just one default scheduler behavior]. Is the default grace_g[12] setting good enough for your workload?

I agree. If anything is required, a simple on/off tunable makes much more sense. Much like I suggested ages ago with an "interactive" switch which was rather unpopular when I first suggested it.

Let me try to explain why on/off is not sufficient.

You notice how Willy said that his notebook is more responsive with tunables set to 0,0? That's important, because it's absolutely true... depending what you're doing. Setting tunables to 0,0 cuts off the idle sleep logic, and the sleep_avg divisor - both of which were put there specifically for interactivity - and returns the scheduler to more or less original O(1) scheduler. You and I both know that these are most definitely needed in a Desktop environment. For instance, if Willy starts editing code in X, and scrolls while something is running in the background, he'll suddenly say hey, maybe this _ain't_ more responsive, because all of a sudden the starvation added with the interactivity logic will be sorely missed as my throttle wrings X's neck.

How long should Willy be able to scroll without feeling the background, and how long should Apache be able to starve his shell. They are one and the same, and I can't say, because I'm not Willy. I don't know how to get there from here without tunables. Picking defaults is one thing, but I don't know how to make it one-size-fits-all. For the general case, the values delivered will work fine. For the apache case, they absolutely 100% guaranteed will not.

Quoted 7 lines · Mike Galbraith

How long should Willy be able to scroll without feeling the background, and how long should Apache be able to starve his shell. They are one and the same, and I can't say, because I'm not Willy. I don't know how to get there from here without tunables. Picking defaults is one thing, but I don't know how to make it one-size-fits-all. For the general case, the values delivered will work fine. For the apache case, they absolutely 100% guaranteed will not.

So how do you propose we tune such a beast then? Apache users will use off, everyone else will have no idea but to use the defaults.

Quoted 9 lines · Con Kolivas

Quoted 7 lines · Mike Galbraith

How long should Willy be able to scroll without feeling the background, and how long should Apache be able to starve his shell. They are one and the same, and I can't say, because I'm not Willy. I don't know how to get there from here without tunables. Picking defaults is one thing, but I don't know how to make it one-size-fits-all. For the general case, the values delivered will work fine. For the apache case, they absolutely 100% guaranteed will not.

Quoted 2 lines

So how do you propose we tune such a beast then? Apache users will use off, everyone else will have no idea but to use the defaults.

Set for desktop, which is intended to mostly emulate what we have right now, which most people are quite happy with. The throttle will still nail most of the corner cases, and the other adjustments nail the majority of what's left. That leaves the hefty server type loads as what certainly will require tuning. They always need tuning.

Quoted 13 lines · Mike Galbraith

Quoted 11 lines · Con Kolivas

Quoted 7 lines · Mike Galbraith

How long should Willy be able to scroll without feeling the background, and how long should Apache be able to starve his shell. They are one and the same, and I can't say, because I'm not Willy. I don't know how to get there from here without tunables. Picking defaults is one thing, but I don't know how to make it one-size-fits-all. For the general case, the values delivered will work fine. For the apache case, they absolutely 100% guaranteed will not.

So how do you propose we tune such a beast then? Apache users will use off, everyone else will have no idea but to use the defaults.

Quoted 5 lines

Set for desktop, which is intended to mostly emulate what we have right now, which most people are quite happy with. The throttle will still nail most of the corner cases, and the other adjustments nail the majority of what's left. That leaves the hefty server type loads as what certainly will require tuning. They always need tuning.

That still sounds like just on/off to me. Default for desktop and 0,0 for server. Am I missing something?

Cheers,
Con

Quoted 15 lines · Con Kolivas

Quoted 14 lines · Mike Galbraith

Quoted 12 lines · Con Kolivas

Quoted 8 lines · Mike Galbraith

How long should Willy be able to scroll without feeling the background, and how long should Apache be able to starve his shell.
They are one and the same, and I can't say, because I'm not Willy. I don't know how to get there from here without tunables. Picking
defaults is one thing, but I don't know how to make it one-size-fits-all. For the general case, the values delivered will work fine. For the apache case, they absolutely 100% guaranteed will not.

So how do you propose we tune such a beast then? Apache users will use off, everyone else will have no idea but to use the defaults.

Quoted 8 lines

Quoted 5 lines

Set for desktop, which is intended to mostly emulate what we have right now, which most people are quite happy with. The throttle will still nail most of the corner cases, and the other adjustments nail the majority of what's left. That leaves the hefty server type loads as what certainly will require tuning. They always need tuning.

That still sounds like just on/off to me. Default for desktop and 0,0 for server. Am I missing something?

Believe it or not, there *are* people running their servers with full graphical environments. At the place we first encountered the interactivity problem with my load-balancer, they first installed in on a full FC2 with the OpenGL screen saver... No need to say they had scaling difficulties and trouble to log in !

Although that's a stupid thing to do, what I want to show is that even on servers, you can't easily predict the workload. Maybe a server which often forks processes for dedicated tasks (eg: monitoring) would prefer running between "desktop" and "server" mode.

I give up. Add as many tunables as you like in as many places as possible that even less people will understand. You've already told me you'll be running 0,0.

Quoted 3 lines · Con Kolivas

I give up. Add as many tunables as you like in as many places as possible that even less people will understand. You've already told me you'll be running 0,0.

Instead of giving up, how about look at the code and make a suggestion for improvement? It's not an easy problem, as you're well aware.

I really don't see why you're (seemingly) getting irate. Tunables for this are no different that tunables like CHILD_PENALTY etc etc etc. How many casual users know those exist, much less understand them?

I actually believe the same effect can be had by a tiny modification to enable/disable the estimator anyway.

Quoted 2 lines · Con Kolivas

I actually believe the same effect can be had by a tiny modification to enable/disable the estimator anyway.

Just for argument's sake it would look something like this.

Cheers,
Con
---
Add sysctl to enable/disable cpu scheduer interactivity estimator

Quoted 10 lines · Con Kolivas

Quoted 2 lines · Con Kolivas

I actually believe the same effect can be had by a tiny modification to enable/disable the estimator anyway.

Just for argument's sake it would look something like this.

Cheers,
Con
---
Add sysctl to enable/disable cpu scheduer interactivity estimator

At least, in May 2005, the equivalent of this patch I tested on 2.6.11.7 considerably improved responsiveness, but there was still this very annoying slowdown when the load increased. vmstat delays increased by one second every 10 processes. I retried again around 2.6.14 a few months ago, and it was the same. Perhaps Mike's code and other changes in 2.6-mm really fix the initial problem (array switching ?) and then only the interactivity boost is causing the remaining trouble ?

Quoted 2 lines · Con Kolivas

I actually believe the same effect can be had by a tiny modification to enable/disable the estimator anyway.

Just for argument's sake it would look something like this.

Quoted 25 lines · Mike Galbraith

Quoted 9 lines · Con Kolivas

Quoted 4 lines · Ingo Molnar

great work by Mike! One detail: i'd like there to be just one default throttling value, i.e. no grace_g tunables [so that we have just one default scheduler behavior]. Is the default grace_g[12] setting good enough for your workload?

I agree. If anything is required, a simple on/off tunable makes much more sense. Much like I suggested ages ago with an "interactive" switch which was rather unpopular when I first suggested it.

Let me try to explain why on/off is not sufficient.

You notice how Willy said that his notebook is more responsive with tunables set to 0,0? That's important, because it's absolutely true... depending what you're doing. Setting tunables to 0,0 cuts off the idle sleep logic, and the sleep_avg divisor - both of which were put there specifically for interactivity - and returns the scheduler to more or less original O(1) scheduler. You and I both know that these are most definitely needed in a Desktop environment. For instance, if Willy starts editing code in X, and scrolls while something is running in the background, he'll suddenly say hey, maybe this _ain't_ more responsive, because all of a sudden the starvation added with the interactivity logic will be sorely missed as my throttle wrings X's neck.

Quoted 7 lines

How long should Willy be able to scroll without feeling the background, and how long should Apache be able to starve his shell. They are one and the same, and I can't say, because I'm not Willy. I don't know how to get there from here without tunables. Picking defaults is one thing, but I don't know how to make it one-size-fits-all. For the general case, the values delivered will work fine. For the apache case, they absolutely 100% guaranteed will not.

So how do you propose we tune such a beast then? Apache users will use off, everyone else will have no idea but to use the defaults.

Cheers,
Con

What you describe is exactly a case for a tunable. Different people with different workloads want different values. Seems fair enough. After all, we already have /proc/sys/vm/swappiness, and things like that for the same reason : the default value should suit most users, and the ones with knowledge and different needs can tune their system. Maybe grace_{g1,g2} should be renamed to be more explicit, may be we can automatically tune one from the other and let only one tunable. But if both have a useful effect, I don't see a reason for hiding them.

great work by Mike! One detail: i'd like there to be just one default throttling value, i.e. no grace_g tunables [so that we have just one default scheduler behavior]. Is the default grace_g[12] setting good enough for your workload?

Quoted 4 lines · Ingo Molnar

great work by Mike! One detail: i'd like there to be just one default throttling value, i.e. no grace_g tunables [so that we have just one default scheduler behavior]. Is the default grace_g[12] setting good enough for your workload?

I can make the knobs compile time so we don't see random behavior reports, but I don't think they can be totally eliminated. Would that be sufficient?

If so, the numbers as delivered should be fine for desktop boxen I think. People who are building custom kernels can bend to fit as always.

-Mike

Quoted 4 lines · Mike Galbraith

I can make the knobs compile time so we don't see random behavior reports, but I don't think they can be totally eliminated. Would that be sufficient?

Quoted 3 lines

If so, the numbers as delivered should be fine for desktop boxen I think. People who are building custom kernels can bend to fit as always.

That would suit me perfectly. I think I would set them both to zero. It's not clear to me what workload they can help, it seems that they try to allow a sometimes unfair scheduling.

Quoted 3 lines · Willy Tarreau

That would suit me perfectly. I think I would set them both to zero. It's not clear to me what workload they can help, it seems that they try to allow a sometimes unfair scheduling.

Correct. Massively unfair scheduling is what interactivity requires.

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Are you having a bad hair day??

Quoted 10 lines · Mike Galbraith

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Quoted 1 line

Are you having a bad hair day??

My hair is approximately 3mm long so it's kinda hard for that to happen.

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Quoted 4 lines · Con Kolivas

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

i believe such artifacts are due to array switches not happening (due to the workload getting queued back to rq->active, not rq->expired), and 'ls' only gets a timeslice once in a while, every STARVATION_LIMIT times. I.e. such workloads penalize the CPU-bound 'ls' process quite heavily.

Quoted 6 lines · Ingo Molnar

Quoted 4 lines · Con Kolivas

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Quoted 5 lines

i believe such artifacts are due to array switches not happening (due to the workload getting queued back to rq->active, not rq->expired), and 'ls' only gets a timeslice once in a while, every STARVATION_LIMIT times. I.e. such workloads penalize the CPU-bound 'ls' process quite heavily.

With nothing else running on the machine it should still get all the cpu no matter which array it's on though.

Quoted 10 lines · Mike Galbraith

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Quoted 1 line

Are you having a bad hair day??

My hair is approximately 3mm long so it's kinda hard for that to happen.

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Quoted 4 lines · Con Kolivas

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

What I was talking about when I mentioned scrolling was rendering.

Quoted 6 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Quoted 1 line

What I was talking about when I mentioned scrolling was rendering.

I'm talking about the long standing report that 'ls' takes 10 times longer on 2.6 90% of the time you run it, and doing 'ls | cat' makes it run as fast as 2.4. This is what Willy has been fighting with.

Quoted 9 lines · Con Kolivas

Quoted 7 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

What I was talking about when I mentioned scrolling was rendering.

Quoted 3 lines

I'm talking about the long standing report that 'ls' takes 10 times longer on 2.6 90% of the time you run it, and doing 'ls | cat' makes it run as fast as 2.4. This is what Willy has been fighting with.

ah. That's i think a gnome-terminal artifact - it does some really stupid dynamic things while rendering, it 'skips' certain portions of rendering, depending on the speed of scrolling. Gnome 2.14 ought to have that fixed i think.

Ingo

Ah no, I never use those montruous environments ! xterm is already heavy. [...]

[...] don't you remember, we found that doing "ls" in an xterm was waking the xterm process for every single line, which in turn woke the X server for a one-line scroll, while adding the "|cat" acted like a buffer with batched scrolls. Newer xterms have been improved to trigger jump scroll earlier and don't exhibit this behaviour even on non-patched kernels. However, sshd still shows the same problem IMHO.

Quoted 2 lines · Willy Tarreau

Ah no, I never use those montruous environments ! xterm is already heavy. [...]

[ offtopic note: gnome-terminal developers claim some massive speedups
in Gnome 2.14, and my experiments on Fedora rawhide seem to corraborate that - gnome-term is now faster (for me) than xterm. ]

Quoted 6 lines

[...] don't you remember, we found that doing "ls" in an xterm was waking the xterm process for every single line, which in turn woke the X server for a one-line scroll, while adding the "|cat" acted like a buffer with batched scrolls. Newer xterms have been improved to trigger jump scroll earlier and don't exhibit this behaviour even on non-patched kernels. However, sshd still shows the same problem IMHO.

yeah. The "|cat" changes the workload, which gets rated by the scheduler differently. Such artifacts are inevitable once interactivity heuristics are strong enough to significantly distort the equal sharing of CPU time.

Can you explain why terminal output ping-pongs back and forth between taking a certain amount of time, and approximately 10x longer?

Why does it ping-pong between taking ~0.08s and ~0.75s like that? The behavior is completely reproducible.

Do any of the above WAGs match what you see? If so, then perhaps it's random just due to the order in which the tasks get initially scheduled (dmesg vs ssh, or dmesg vs xterm vs X -- er, though I guess in that latter case there's really <thinks> three separate timings that you'd get back, as the triple set of tasks could be in one of six orderings, one fast, one slow, and four equally mixed between the two).

Quoted 6 lines · Mike Galbraith

Quoted 4 lines · Con Kolivas

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Quoted 1 line

What I was talking about when I mentioned scrolling was rendering.

I'm talking about the long standing report that 'ls' takes 10 times longer on 2.6 90% of the time you run it, and doing 'ls | cat' makes it run as fast as 2.4. This is what Willy has been fighting with.

Oh. I thought you were calling me a _moron_ :)

Quoted 10 lines · Mike Galbraith

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Quoted 1 line

Are you having a bad hair day??

My hair is approximately 3mm long so it's kinda hard for that to happen.

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Cheers,
Con

Quoted 11 lines · Con Kolivas

Quoted 10 lines · Mike Galbraith

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Quoted 7 lines

Quoted 1 line

Are you having a bad hair day??

My hair is approximately 3mm long so it's kinda hard for that to happen.

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Con, those cycles are not "magic", if you look at the numbers, the time is not spent in the process itself. From what has been observed since the beginning, it is spent :
- in other processes which are starvating the CPU (eg: X11 when xterm scrolls)
- in context switches when you have a pipe somewhere and the CPU is bouncing between tasks.

Concerning your angriness about me being OK with (0,0) and still asking for tunables, it's precisely because I know that *my* workload is not everyone else's, and I don't want to conclude too quickly that there are only two types of workloads.

Maybe you're right, maybe you're wrong. At least you're right for as long as no other workload has been identified. But thinking like this is like some time ago when we thought that "if it runs XMMS without skipping, it'll be OK for everyone".

Quoted 28 lines · Willy Tarreau

Quoted 11 lines · Con Kolivas

Quoted 10 lines · Mike Galbraith

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Quoted 7 lines

Quoted 1 line

Are you having a bad hair day??

My hair is approximately 3mm long so it's kinda hard for that to happen.

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Con, those cycles are not "magic", if you look at the numbers, the time is not spent in the process itself. From what has been observed since the beginning, it is spent :
- in other processes which are starvating the CPU (eg: X11 when xterm scrolls)
- in context switches when you have a pipe somewhere and the CPU is bouncing between tasks.

Quoted 4 lines

Concerning your angriness about me being OK with (0,0) and still asking for tunables, it's precisely because I know that *my* workload is not everyone else's, and I don't want to conclude too quickly that there are only two types of workloads.

Well, perhaps we can assume there are only two types of workloads and wait for a test case that will show the assumption is wrong?

Quoted 4 lines

Maybe you're right, maybe you're wrong. At least you're right for as long as no other workload has been identified. But thinking like this is like some time ago when we thought that "if it runs XMMS without skipping, it'll be OK for everyone".

However, we should not try to anticipate every possible kind of workload IMHO.

Greetings,
Rafael

Quoted 29 lines · Rafael J. Wysocki

Quoted 28 lines · Willy Tarreau

Quoted 11 lines · Con Kolivas

Quoted 10 lines · Mike Galbraith

Quoted 6 lines · Con Kolivas

The yardstick for changes is now the speed of 'ls' scrolling in the console. Where exactly are those extra cycles going I wonder? Do you think the scheduler somehow makes the cpu idle doing nothing in that timespace? Clearly that's not true, and userspace is making something spin unnecessarily, but we're gonna fix that by modifying the scheduler.... sigh

*Blink*

Quoted 7 lines

Quoted 1 line

Are you having a bad hair day??

My hair is approximately 3mm long so it's kinda hard for that to happen.

What you're fixing with unfairness is worth pursuing. The 'ls' issue just blows my mind though for reasons I've just said. Where are the magic cycles going when nothing else is running that make it take ten times longer?

Con, those cycles are not "magic", if you look at the numbers, the time is not spent in the process itself. From what has been observed since the beginning, it is spent :
- in other processes which are starvating the CPU (eg: X11 when xterm scrolls)
- in context switches when you have a pipe somewhere and the CPU is bouncing between tasks.

Quoted 7 lines

Quoted 4 lines

Concerning your angriness about me being OK with (0,0) and still asking for tunables, it's precisely because I know that *my* workload is not everyone else's, and I don't want to conclude too quickly that there are only two types of workloads.

Well, perhaps we can assume there are only two types of workloads and wait for a test case that will show the assumption is wrong?

It would certainly fit most usages, but as soon as we find another group of users complaining, we will add another sysctl just for them ? Perhaps we could just resume the two current sysctls into one called "interactivity_boost" with a value between 0 and 100, with the ability for any user to increase or decrease it easily ? Mainline would be pre-configured with something reasonable, like what Mike proposed as default values for example, and server admins would only set it to zero while desktop-intensive users could increase it a bit if they like to.

Quoted 11 lines · Willy Tarreau

Quoted 7 lines · Mike Galbraith

I can make the knobs compile time so we don't see random behavior reports, but I don't think they can be totally eliminated. Would that be sufficient?

If so, the numbers as delivered should be fine for desktop boxen I think. People who are building custom kernels can bend to fit as always.

Quoted 3 lines

That would suit me perfectly. I think I would set them both to zero. It's not clear to me what workload they can help, it seems that they try to allow a sometimes unfair scheduling.

Correct. Massively unfair scheduling is what interactivity requires.

Quoted 8 lines · Mike Galbraith

Quoted 3 lines · Willy Tarreau

That would suit me perfectly. I think I would set them both to zero. It's not clear to me what workload they can help, it seems that they try to allow a sometimes unfair scheduling.

Correct. Massively unfair scheduling is what interactivity requires.

Selective unfairness not massive unfairness is what's required. The hard part is automating the selectiveness especially when there are three quite different types of task that need special treatment: 1) the X server, 2) normal interactive tasks and 3) media streamers; each of which has different behavioural characteristics. A single mechanism that classifies all of these as "interactive" will unfortunately catch a lot of tasks that don't belong to any one of these types.

Quoted 9 lines · Peter Williams

Quoted 7 lines · Mike Galbraith

Quoted 3 lines · Willy Tarreau

That would suit me perfectly. I think I would set them both to zero. It's not clear to me what workload they can help, it seems that they try to allow a sometimes unfair scheduling.

Quoted 4 lines

Quoted 2 lines

Correct. Massively unfair scheduling is what interactivity requires.

Selective unfairness not massive unfairness is what's required. The hard part is automating the selectiveness especially when there are three quite different types of task that need special treatment: 1) the X server, 2) normal interactive tasks and 3) media streamers; each of which has different behavioural characteristics. A single mechanism that classifies all of these as "interactive" will unfortunately catch a lot of tasks that don't belong to any one of these types.

Yes, selective would be nice, but it's still massively unfair that is required. There is no criteria available for discrimination, so my patches don't even try to classify, they only enforce the rules. I don't classify X as interactive, I merely provide a mechanism which enables X to accumulate the cycles an interactive task needs to be able to perform by actually _being_ interactive, by conforming to the definition of sleep_avg.

Fortunately, it uses that mechanism. I do
nothing more than trade stout rope for good behavior. I anchor one end to a boulder, the other to a task's neck. The mechanism is agnostic. The task determines whether it gets hung or not, and the user determines how long the rope is.

Greetings,

I was asked to do some interbench runs, with various throttle settings, see below. I'll not attempt to interpret results, only present raw data for others to examine.

Tested throttling patches version is V24, because while I was compiling 2.6.16-rc6-mm2 in preparation for comparison, I found I'd introduced an SMP buglet in V23. Something good came from the added testing whether the results are informative or not :)

Quoted 10 lines · Mike Galbraith

Greetings,

I was asked to do some interbench runs, with various throttle settings, see below. I'll not attempt to interpret results, only present raw data for others to examine.

Tested throttling patches version is V24, because while I was compiling 2.6.16-rc6-mm2 in preparation for comparison, I found I'd introduced an SMP buglet in V23. Something good came from the added testing whether the results are informative or not :)

Thanks!

I wonder why the results are affected even without any throttling settings but just patched in? Specifically I'm talking about deadlines met with video being sensitive to this. Were there any other config differences between the tests? Changing HZ would invalidate the results for example. Comments?

Quoted 5 lines · Con Kolivas

I wonder why the results are affected even without any throttling settings but just patched in? Specifically I'm talking about deadlines met with video being sensitive to this. Were there any other config differences between the tests? Changing HZ would invalidate the results for example. Comments?

I wondered the same. The only difference then is the lower idle sleep prio, tighter timeslice enforcement, and the SMP buglet fix for now < p->timestamp due to SMP rounding. Configs are identical.

Quoted 10 lines · Mike Galbraith

Quoted 5 lines · Con Kolivas

I wonder why the results are affected even without any throttling settings but just patched in? Specifically I'm talking about deadlines met with video being sensitive to this. Were there any other config differences between the tests? Changing HZ would invalidate the results for example. Comments?

I wondered the same. The only difference then is the lower idle sleep prio, tighter timeslice enforcement, and the SMP buglet fix for now < p->timestamp due to SMP rounding. Configs are identical.

Ok well if we're going to run with this set of changes then we need to assess the affect of each change and splitting them up into separate patches would be appropriate normally anyway. That will allow us to track down which particular patch causes it. That won't mean we will turn down the change based on that one result, though, it will just help us understand it better.

Quoted 12 lines · Con Kolivas

Quoted 10 lines · Mike Galbraith

Quoted 5 lines · Con Kolivas

I wonder why the results are affected even without any throttling settings but just patched in? Specifically I'm talking about deadlines met with video being sensitive to this. Were there any other config differences between the tests? Changing HZ would invalidate the results for example. Comments?

I wondered the same. The only difference then is the lower idle sleep prio, tighter timeslice enforcement, and the SMP buglet fix for now < p->timestamp due to SMP rounding. Configs are identical.

Quoted 5 lines

Ok well if we're going to run with this set of changes then we need to assess the affect of each change and splitting them up into separate patches would be appropriate normally anyway. That will allow us to track down which particular patch causes it. That won't mean we will turn down the change based on that one result, though, it will just help us understand it better.

I'm investigating now.

Nothing conclusive. Some of the difference may be because interbench has a dependency on the idle sleep path popping tasks in a prio 16 instead of 18. Some of it may be because I'm not restricting IO, doing that makes a bit of difference. Some of it is definitely plain old jitter.

virgin

throttle patches with throttling disabled

minus idle sleep

minus don't restrict IO

Quoted 5 lines · Mike Galbraith

Nothing conclusive. Some of the difference may be because interbench has a dependency on the idle sleep path popping tasks in a prio 16 instead of 18. Some of it may be because I'm not restricting IO, doing that makes a bit of difference. Some of it is definitely plain old jitter.

Thanks for those! Just a clarification please

Quoted 1 line

virgin

I assume 2.6.16-rc6-mm2 ?

Quoted 2 lines

throttle patches with throttling disabled

With your full patchset but no throttling enabled?

Quoted 2 lines

minus idle sleep

Full patchset -throttling-idlesleep ?

Quoted 2 lines

minus don't restrict IO

Full patchset -throttling-idlesleep-restrictio ?

Can you please email the latest separate patches so we can see them in isolation? I promise I won't ask for any more interbench numbers any time soon :)

I've separated the buglet fix parts from the rest, so there are four patches instead of two. I've also hidden the knobs, though for the testing phase at least, I personally think it would be better to leave the knobs there for people to twiddle. Something Willy said indicated to me that 'credit' would be more palatable than 'grace', so I've renamed and updated comments to match. I think it might look better, but can't know since 'grace' was perfectly fine for my taste buds ;-)

I'll post as soon as I do some more cleanup pondering and verification.

Quoted 4 lines · Con Kolivas

Thinking some more on this I wonder if SCHED_BATCH isn't a strong enough scheduling hint if it's not suitable for such an application. Ingo do you think we could make SCHED_BATCH tasks always wake up on the expired array?

yep, i think that's a good idea. In the worst case the starvation timeout should kick in.

To increase the strength of SCHED_BATCH as a scheduling hint we can activate batch tasks on the expired array since by definition they are latency insensitive tasks.

Signed-off-by Con Kolivas <[email protected]>

Ok here's a patch that does exactly that. Without an "inline" hint, gcc 4.1.0 chooses not to inline this function. I can't say I have a strong opinion about whether it should be inlined or not (93 bytes larger inlined), so I've decided not to given the current trend.

Index: linux-2.6.16-rc6-mm1/kernel/sched.c
===================================================================

kernel/sched.c +0 -1

@@ -737,9 +737,12 @@ static inline void dec_nr_running(task_t
 /*
  * __activate_task - move a task to the runqueue.
  */
-static inline void __activate_task(task_t *p, runqueue_t *rq)

kernel/sched.c static inline void dec_nr_running(task_t · line 747

Quoted 10 lines · Con Kolivas

kernel/sched.c +5 -2

-static inline void __activate_task(task_t *p, runqueue_t *rq)
+static void __activate_task(task_t *p, runqueue_t *rq)
 {
-	enqueue_task(p, rq->active);
+	if (batch_task(p))
+		enqueue_task(p, rq->expired);
+	else
+		enqueue_task(p, rq->active);
 	inc_nr_running(p, rq);
 }

I prefer:

   prio_array_t *target = rq->active;
   if (batch_task(p))
     target = rq->expired;
   enqueue_task(p, target);

Because gcc can use things like predicated instructions for it. But perhaps it is smart enough these days to recognise this? At least in the past I have seen it start using cmov after doing such a conversion.

At any rate, I think it looks nicer as well. IMO, of course.

Quoted 25 lines · Nick Piggin

Quoted 10 lines · Con Kolivas

kernel/sched.c +1 -1

-static inline void __activate_task(task_t *p, runqueue_t *rq)
+static void __activate_task(task_t *p, runqueue_t *rq)

{

kernel/sched.c +4 -1

-	enqueue_task(p, rq->active);
+	if (batch_task(p))
+		enqueue_task(p, rq->expired);
+	else
+		enqueue_task(p, rq->active);

	inc_nr_running(p, rq);
}

I prefer:

  prio_array_t *target = rq->active;
  if (batch_task(p))
    target = rq->expired;
  enqueue_task(p, target);

Because gcc can use things like predicated instructions for it. But perhaps it is smart enough these days to recognise this? At least in the past I have seen it start using cmov after doing such a conversion.

Quoted 1 line

At any rate, I think it looks nicer as well. IMO, of course.

Well on my one boring architecture here is a before and after, gcc 4.1.0 with optimise for size kernel config:

I'm not attached to the style, just the feature. If you think it's warranted I'll change it.

Quoted 2 lines · Con Kolivas

I'm not attached to the style, just the feature. If you think it's warranted I'll change it.

At least other archtectures might be able to make better use of it, and I agree even for i386 the code looks better (and slightly smaller).

I guess it isn't doing the cmov because it doesn't want to do the extra load in the common case, which is fair enough (are you compiling for a pentiumpro+, without generic x86 support?

what about if you
turn off optimise for size?)

At least other archtectures might be able to make better use of it, and I agree even for i386 the code looks better (and slightly smaller).

Good enough for me. Here's a respin, thanks!

Signed-off-by Con Kolivas <[email protected]>

I'm not attached to the style, just the feature. If you think it's warranted I'll change it.

Hi,

Quoted 2 lines · Con Kolivas

I'm not attached to the style, just the feature. If you think it's warranted I'll change it.

Seconded.

An even nicer way (this solution seems somewhat asymmetric) than

   prio_array_t *target = rq->active;
   if (batch_task(p))
     target = rq->expired;
   enqueue_task(p, target);

may be

   prio_array_t *target;
   if (batch_task(p))
     target = rq->expired;
   else
     target = rq->active;
   enqueue_task(p, target);

But this discussion is clearly growing out of control now ;)

Hi,

Quoted 1 line · Con Kolivas

I'm not attached to the style, just the feature. If you think it's warranted I'll change it.

Seconded.

An even nicer way (this solution seems somewhat asymmetric) than

   prio_array_t *target = rq->active;
   if (batch_task(p))
     target = rq->expired;
   enqueue_task(p, target);

may be

   prio_array_t *target;
   if (batch_task(p))
     target = rq->expired;
   else
     target = rq->active;
   enqueue_task(p, target);

Quoted 5 lines · Con Kolivas

Swap prefetching doesn't use very much cpu but spends a lot of time waiting on disk in uninterruptible sleep. This means it won't get preempted often even at a low nice level since it is seen as sleeping most of the time. We want to minimise its cpu impact so yield where possible.

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?

From the discussion here it seems this problem is caused by a *general*

Hi,

Quoted 7 lines · Andrew Morton

Quoted 5 lines · Con Kolivas

Swap prefetching doesn't use very much cpu but spends a lot of time waiting on disk in uninterruptible sleep. This means it won't get preempted often even at a low nice level since it is seen as sleeping most of the time. We want to minimise its cpu impact so yield where possible.

Quoted 6 lines

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?

This problem occurs due to giving a priority boost to processes that are sleeping a lot (e.g. in this case, I/O, from disk), right? Forgive me my possibly less insightful comments, but maybe instead of adding crude specific hacks (namely, yield()) to each specific problematic process as it comes along (it just happens to be the swap prefetch thread this time) there is a *general way* to give processes with lots of disk I/O sleeping much smaller amounts of boost in order to get them preempted more often in favour of an actually much more critical process (game)?

Quoted 1 line

From the discussion here it seems this problem is caused by a *general*

miscalculation of processes sleeping on disk I/O a lot.

Thus IMHO this problem should be solved in a general way if at all possible.