2.5.74 released.

[bssteph]

I return to good news, I see. Downloading mm3 right now, but likely won't test until this afternoon (it's 5 am now... ).

Lovechild: Will gladly test; should the SCHED_SOFTRR patch be used in conjunction with Con's OXint patches, or should I patch a virgin 2.5.74 kernel?

Gotta zip: sleep deprivation is making my eyes jitter back and forth randomly and I'm getting dizzy

[Lovechild]

[Tuna]

zatalian: do you have SMP enabled? try without. my kernel hung at the same spot, and disableing SMP did the trick for me.

other issues i experienced with the kernel:

USB Mouse only wants to work if ACPI disabled. (acpi=off as kernel parameter)

nvidia module is not working right of the box (tested on mm3).
normally it would exit with that well known DMA error. but at first i was getting this:

[zatalian]

i have a dual p3, so disabling smp is not an option for me.

[Safrax]

How can I make a patch?

[daen1543]

[thubble]

[Safrax]

Thanks Thubble. That did the trick. I'll have a patch against 2.5.74-mm3 ready soon.

I have the patch ready but no place to host it. Its currently 2.4KB in size.

[bssteph]

-mm3 + O4int + granularity + SOFTRR works, but feels like a bit of a regression. Got some mouse chop when Mozilla was rendering, didn't have that in just O3int + granularity. Will likely revert to -mm3 + granularity + SOFTRR.

I think I'm understanding what's going on with SOFTRR now, and it seems nice. Had XMMS use realtime priority (not running as root), and it seemed to not lag up as badly (I don't know what it is, but right now my Nautilus + XMMS blues are back, and with a vengance) as before. I'm assuming the patch has the realtime looks the same to userspace, therefore XMMS was using SOFTRR? If I'm wrong please correct. Starting that recompile now.

[bssteph]

[Lovechild]

Davide's idea is to follow text book scheduler design - less time more freqently to interactive tasks since we don't want them to saturate the CPU and thus starve other tasks, and longer time, less frequent for background jobs - at least that's what he described in his first mail.

I would set
CHILD_PENALTY to 95
and MAX TIMESLICE around 100-120, MIN stays at 10.

with this approach, since we want to deligate exponential rates from lowest to highest nice levels.

The problem of course is that the current scheduler scheme do not properly handle the two keys to scheduling seperately - Urgency and importance.

See sound, video, etc. may not be important but it's urgent - but the current nice scheme is very one dimensional.

Thus to provide handling of urgency, we have what's called interactivity - but this approach isn't really complete in it's current form.

I would like a setup that put more weight on urgency, since this would be the best approach for all setups (servers don't have many urgent tasks - thus importance scaling is the only concern). It seems however that the current setup prefers importance as the determining factor.

Maybe the way to go is to allow each driver to set an interactive flag or level and parse this to the scheduler when handling requests. This could be botched into the current framework with little trouble. It would however be ugly like hell.

Maybe we need to go look at different scheduling technics like adaptive scheduling and such to provide good scalability on the desktop PCs - the old scheduler is dumb enough not to care really, where as the new one seems to try very hard to scale (it's O(1) after all - meaning equal time to handle a request despite the number of processes, the old one scaled linearly to the amount of processes O(n)).

The hard part about scheduling is that no one scheme fits perfectly on all setups - so we have to pick the very best fit for our target, and with Linux taking on the desktop, embedded and the highend - one single scheduler hardly seems to do the trick.

[Safrax]

[Lovechild]

[bssteph]

Safrax: Not why it didn't work, but there was a 0.3 for softrr and it seems the patch you gave me did 0.2. Also it applied granularity, which seemed bad for me, but then again, I remember my performance of .73+O1,2,3int being better than .74-mm3+O4.. Granularity will patch fine on its own, I imagine.

Anyway, the patch's actual error was that it complained every hunk was malformed. This may have been because of the board software replacing tabs with spaces, which I forgot about. But either way, the tabbing was enough to just have me do it myself. I'd only noticed it when I tried applying the patch.

Lovechild: Having drivers say how they wanted to be treated is probably the easiest, but as you said, certainly messy. And in the end it'd be nice if the scheduler were just good enough to do it on its own.

How much of these issues are handled by the elevators?

And the way interactivity is working now, does it say "I'm something that's certainly interacting with the user"? Because it seems a nice indication, but as far as I can tell from what you said, the better statement for these processes is "This needs to be done NOW"...the urgency.
While I was out I thought of a couple things that would be interesting to try with the scheduler, but never felt like actual fixes. Just workarounds. And admittedly, I'm not entirely knowledgable at this, but I gave it a think.

Anyway. O4+softrr is nice, there's a regression since my .73+O1,2,3 kernel, but that seems to have come from something else, as just .74-mm3 seemed slow. Once the reiserfs fix gets merged I'll probably leave mm again and just do sched patches.

(this post would have been more timely but I was literally dragged to go see T3 about halfway through it)

[AlterEgo]

2.5.75 is out