xx-sources

Evil Dark Archon · Posted: Sun Oct 03, 2004 9:32 am Post subject:

here's a compile error that i'm pretty sure is not related to -mm

xiphux · Posted: Sun Oct 03, 2004 2:53 pm Post subject:

Ah, you're on UP, right? The SMP functions are defined as empty macros for UP, but since I run SMP, I didn't come across those errors. I conditionalized kick_process and sched_exec and committed to cvs; let me know if you see others.

Evil Dark Archon · Posted: Sun Oct 03, 2004 9:37 pm Post subject:

i still get a compile error on kernel/sched.c

xiphux · Posted: Sun Oct 03, 2004 10:00 pm Post subject:

Ergh, I forgot about that little nicksched bit. I fixed it in cvs. As for the non-smp errors; I'll try to go through and find as much of it as possible, but you might just want to leave smp on for now.

Evil Dark Archon · Posted: Mon Oct 04, 2004 6:30 am Post subject:

the errors just keep on coming, this time an undefined symbol

xiphux · Posted: Mon Oct 04, 2004 7:09 am Post subject:

Yeah, with a massive rewrite like this, shit was bound to happen...
The xsched thing is probably just something I forgot to conditionalize. And unfortunately, I haven't gotten all the exports right yet, since I only use a couple modules. Maybe a make allyesconfig is in order...

However, I would like to report that I have successfully gotten the boot-time scheduler selection to work! The key was in the architecture-specific early parameter parsing. (For example, disabling hyperthreading, disabling acpi interrupts, etc... the scheduler needs to know that stuff) At the moment I've only added x86 support since it's what I and most of the rest of the world use. But if you need a different arch, I can add it.
I also ran uniprocessor compiles, so that should hopefully be sorted out.
Unfortunately, I can't commit it tonight. I've been up so late kernel hacking that as it is, I'll only get 3 hours of sleep for my first class. There are still some bugs that I want to fix - for example, staircase sometimes oopses on boot, nicksched sometimes oopses on shutdown, etc. I also want to add voluntary preempt again, which will take longer than usual since the sched code is very different now. But I promise, I'll do all that tomorrow...

This is great! It might still be in its infancy, and it might be a rocky path getting there, but I'm glad that a major project like this is finally coming to fruition. (Sorry, this is the biggest single hack that I've done to date, so I'm excited. I'll drink to that...)

Evil Dark Archon · Posted: Mon Oct 04, 2004 9:43 am Post subject:

xiphux · Posted: Wed Oct 06, 2004 1:18 am Post subject:

Ok, I've updated cvs with -mm2, the latest voluntary preempt, and the working boot-selectable schedulers. The boot parameter is "scheduler=", and the options are:

scheduler=default
scheduler=nicksched
scheduler=staircase
scheduler=xsched

And the boot-time scheduler config option is still in, so you can choose which it defaults to.

Now i'm going to get cracking on the bugs that have popped up (undefined symbols, missed conditionals, etc etc).

Dunno how the new scheduling code will go for everyone; let me know.

Evil Dark Archon · Posted: Thu Oct 07, 2004 3:45 am Post subject:

latest cvs works great, only one undefined symbol in serial_core (kernel_locked), but i don't use my serial ports anyway, so its not a big deal.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

xiphux · Posted: Thu Oct 07, 2004 4:01 am Post subject:

Did you mess around with the selectable schedulers at all, or did you notice a performance difference or anything? I'm curious to see if my messing around had any bad side effects...

Thanks for the headsup about the undefined symbol, it's so hard to catch them with only one configuration. Let me know if you see any more.

I'll try to re-add the newest versions of vesafb-tng and/or fbsplash, and maybe (finally) make another release, since I've got almost everything I really want in. That is, if I don't hear about any major disasters soon...

Evil Dark Archon · Posted: Thu Oct 07, 2004 5:14 am Post subject:

performance is better than the last cvs version that worked (based on 2.6.9-rc2-mm4), i only compiled staircase in because i don't like to have any more code compiled in the kernel than i need to and i was finally able to compile it without SMP enabled.

*EDIT* I'm getting random lock-ups with staircase, the same lock-ups were present in the previous working version of xx-sources, also, when i put scheduler=xsched (i recompiled the kernel with all the schedulers in it) in my kernel parameters my computer locks up immediately after the display initalizes, i'm going to try with nicksched and default later on. Another thing to note is that i think the staircase lock-ups may be related to reiser4 (i recently converted all my partitions to reiser4), I'm going to see if the same lock-ups occur with default and nicksched, if that's the case than the problem is probably with reiser4.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

4nykey · Apprentice Joined: 11 Feb 2004 Posts: 176

Speaking of undefined symbols, I've got couple:

xiphux · Posted: Thu Oct 07, 2004 4:27 pm Post subject:

4nykey, I fixed the sched_init_smp reference and will commit it to cvs soon. The vesafb error is probably just the changes to fbdev in -mm, so it shouldn't be too hard to track down.

Evil Dark Archon, I run reiser4 on almost all of my system partitions, too, and I've been able to boot into all 4 scheds. Admittedly, I haven't run for any extended period of time with the others, but I'll probably boot into and run staircase for a while to see if I get the same thing. But the xsched thing is weird, since it's the one I always use, so it's usually the one I make sure is working first. What's the last thing(s) that get printed on the screen before the freeze? You might also want to try 'debug' and/or 'initcall_debug'.
If the staircase thing was present in earlier versions, then it may just be that one copy of staircase in xx. (Something was mistyped, incorrectly merged, whatever). I might try a fresh merge when I update to the newest version of Staircase.

Evil Dark Archon · Posted: Thu Oct 07, 2004 8:41 pm Post subject:

well for xsched the last thing it prints is it detecting my IDE controller (amd74xx, nforce 2 chipset), with nicksched it oopses after loading the module for my SATA control (sata_sil). The default scheduler is the only one that works without any problems what-so-ever.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

xiphux · Posted: Thu Oct 07, 2004 9:37 pm Post subject:

Huh, weird. Detects the IDE controller as in, after ethernet card detection and before usb detection?

Basically, I want to detect whether the error is happening in the scheduling initialization, which is the most delicate part due to all my screwing around, or later on, after the scheduler's been initialized. It'll help narrow down which functions to look at.

And also, what does the serial ata oops look like? (like the list of calls it last made in the stack, screw the hex stuff) Did you have any undefined symbols with the module?

And I also _think_ I may have found the staircase thing you were talking about. It's actually a real oops and not a lockup, it's just that when you're in X, you're not really going to see the system console anymore. Try running it in console mode for a bit, maybe do something cpu/disk intensive (it happened to me when I was applying a large stack of patches). The specific oops I saw was in dequeue_task(), as called from schedule(). Since there's only one dequeue_task in schedule (for tasks that are PF_YIELDED), it helps narrow things down, but it still leaves me to figure out _why_ it's oopsing...

Evil Dark Archon · Posted: Thu Oct 07, 2004 10:02 pm Post subject:

i didn't see an oops in console mode, i was running in console mode for quite a while and all it did was lock up. I'll write down the sata oops and post it here when i get the chance (got school in a half-hour).

*EDIT* The last thing to show up for xsched is actually something about ksoftirqd being initialized. and i still get lockups (no oops message) with staircase even with the latest CVS update. I'll have to recompile my kernel with kallsyms to provide a useful oops message for the nicksched bug.

*EDIT 2* 2.6.9-rc3-mm3 is out
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

4nykey · Apprentice Joined: 11 Feb 2004 Posts: 176

I've got tng to compile:

xiphux · Posted: Sun Oct 10, 2004 8:19 pm Post subject:

For some reason, I haven't been able to get onto the forums for the past couple of days, dunno if this was the case with anyone else.

I merged to -mm3, but I was having problems booting until recently. (It turned out to be a combination of HRT being broken as well as a badly merged voluntary-preempt. I dropped HRT and re-merged VP from scratch, and all seems well.)

I also upgraded to the latest staircase, 8.I (or 8.H_test1 if you want to be specific). And I noticed that there were some changes in the exact piece of code that was oopsing out (dequeue_task in schedule()), so hopefully things will be a bit smoother.

One thing you might want to do to test responsiveness is to use the preempt latency timing thing in voluntary-preempt, and see if you get anything informative from that. And you are renicing X for the right schedulers, right? (Renice with nicksched and xsched, leave default for the others)

Actually, I'm not really certain about this, but it's quite possible that preempt is actually _decreasing_ performance. Preempt coding is extremely difficult to get right, since the code no longer executes in a straightforward manner like you write it to. And since I tore the scheduling code apart and redid it, it'll probably take some time and study to get the preempt bits working smoothly. You might want to try disabling preempt and seeing how things are.

I'll add in the bit for vesafb-tng.c shortly, but the fix for vesafb-thread.c is actually not right; io_remap_page_range is not the same thing as remap_page_range. remap_page_range is slowly being abstracted into the more generic remap_pfn_range, which is almost the same thing. remap_page_range takes into account the PAGE_SHIFT, which varies across architectures. But in -mm, they took it out just so things would break so they could find stray instances of remap_page_range. Those two lines should actually look like:

4nykey · Apprentice Joined: 11 Feb 2004 Posts: 176

planet-admin · Posted: Mon Oct 11, 2004 4:30 pm Post subject:

Evil Dark Archon · Posted: Tue Oct 12, 2004 6:32 am Post subject:

so far so good, its good to see staircase working again.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

xiphux · Posted: Wed Oct 13, 2004 2:18 am Post subject:

Committing sources synced with 2.6.9-rc4-mm1 as I type. Also updated to the latest voluntary preempt with the realtime extensions (although enabling the realtime stuff doesn't work for me). Hopefully this kernel will survive so I can make a release before 2.6.9 comes out within the week.

Evil Dark Archon · Posted: Thu Oct 14, 2004 8:28 pm Post subject:

new version of realtime-preemption (-U1) just hit lkml this morning, some of the changes in the -U versions look very interesting.
_________________
This post has been over explained for newb-informing purposes.

Registered Linux user 347334
Abit AV8-3rd eye, AMD Athlon64 3500+ 90nm, ATI Radeon x850 pro

xiphux · Posted: Thu Oct 14, 2004 11:03 pm Post subject:

Yeah, I saw that. I merged U1 and will commit it in a bit, but I've tried it and it's still very, very rusty. All my peripherals don't work because their hardirqs are being preempted (since realtime requires all the preempt options). Plus, I'm noticing that while the realtime kernel has good latency and responds quickly, the overall performance is worse - loads that normally wouldn't make things slow end up dragging things down a lot. (Then, again, I suppose that is the point of the realtime stuff... running few tasks at realtime priority, as opposed to balancing between many normal priority tasks...)

xiphux · Posted: Mon Oct 18, 2004 3:55 am Post subject:

It seems that the kernel development has stagnated a bit, so I decided to make a release. It's been a long time, and it's actually the first release with the boot-selectable schedulers. I don't know if everything will work perfectly, but we'll see. It works for me.

I'm committing to CVS now, then I'll diff and compress a patch, and then roll up the broken-out patches. Should be up within the next hour or so.

There isn't a whole lot different than what's been in CVS up till now. Based on 2.6.9-rc4-mm1. I updated to the latest staircase, 8.K. There isn't any mapped watermark because it's incompatible with Nick's tweaks that have been making their way into -mm.
The latest voluntary preempt, -U4, is in. A note about that: in -U4, the behavior of the max-latency tracing is a little different. The idea of the max-latency tracing is to record the maximum latency, and when a task beats that for a new maximum latency, print out a trace of it. But the behavior in -U4, if I'm reading these traces correctly, is to start with no maximum latency at all. Since the highest latencies on a system _should_ be during the boot process, you'll see a lot of traces go by as it first boots, up until about when it mounts the filesystems. These will have tiny latencies, since we're starting from scratch - 2us max, then 4 us max, then 10 us max, etc. So don't worry about those if you see them. It's really only when a normal user task has a higher latency than the initial boot that it's a concern.
Although, it's been interesting to note the various max boot latencies as I test booted into the different schedulers; the results were for the most part what I expected. Staircase had the lowest max boot latency (low 100's), which makes sense since it's designed for low latency and interactivity. The default came next (low 200s +). Xsched came next, and Nicksched was last - that makes sense, since nicksched is designed for balance and not particularly latency, and xsched uses the nicksched calculations but on a single-array setup, which is slightly more latency-friendly.
Another note, on the issue of irq preemption: while I still can't use hardirq preemption, one thing i've noticed is that my system is actually better _without_ softirq preemption, either. When I have softirq preemption on, ksoftirqd is always eating up over 25% of my processor. When I turn that off, it eases up. I dunno if this is the case with other people's computers...

Unfortunately, there's no splash yet. Spock still doesn't keep up with the -mm fbdev changes, and I really don't blame him.

That's pretty much it. The release is 2.6.9-rc4-xx3, since it went through a couple test phases as xx1 and xx2.
As always, the sourceforge project page:
http://sourceforge.net/projects/xx-sources