Menu
▾
▴
syllable-kernel
|
From: Jake H. <jh...@po...> - 2005-01-28 03:26:48
|
Did Arno Klenke release his kernel patches to anyone in source form? I have his latest kernel.so and the patches from Dec. 30, but nothing else. I sent him a private e-mail so I'm sure I'll hear back from him soon. Also, what is the verdict as far as the stability of Arno's patches? Did the Jan. 23 patch removing the cli()/put_cpu_flags() calls make things better or worse? I'm concerned about Vander's reports of instability during compiles and I'd much rather have a stable kernel that only works on some machines than a kernel that boots on more machines but isn't reliable. It would be nice if we had more comments in the code as to the exact order in which things are happening in the startup sequence, or why the interrupts should or should not be disabled at certain places, as the logic can be quite subtle and confusing at this low level. I'll see what I can do to continue Arno and Daniel's cleanups and add some appropriate comments as I figure stuff out. :-) -Jake |
|
From: Kristian V. D. V. <va...@li...> - 2005-01-28 07:49:48
|
On Friday 28 January 2005 03:26, Jake Hamby wrote: > Also, what is the verdict as far as the stability of Arno's patches? > Did the Jan. 23 patch removing the cli()/put_cpu_flags() calls make > things better or worse? I'm concerned about Vander's reports of > instability during compiles and I'd much rather have a stable kernel > that only works on some machines than a kernel that boots on more > machines but isn't reliable. It fixed booting on SMP (& HT) machines at the expense of stability on SMP and uni machines. I wouldn't consider it a suitable final patch for inclusion in the next release of Syllable without further work to stabalise it. -- Vanders http://www.syllable.org http://www.liqwyd.com |
|
From: Jake H. <jh...@po...> - 2005-01-28 08:59:46
|
Kristian Van Der Vliet wrote: > On Friday 28 January 2005 03:26, Jake Hamby wrote: > >>Also, what is the verdict as far as the stability of Arno's patches? >>Did the Jan. 23 patch removing the cli()/put_cpu_flags() calls make >>things better or worse? I'm concerned about Vander's reports of >>instability during compiles and I'd much rather have a stable kernel >>that only works on some machines than a kernel that boots on more >>machines but isn't reliable. > > > It fixed booting on SMP (& HT) machines at the expense of stability on SMP and > uni machines. I wouldn't consider it a suitable final patch for inclusion in > the next release of Syllable without further work to stabalise it. Okay, that's what I thought. I was a little concerned because, if anything, we should be _adding_ SMP sychronization mutexes, not removing them, unless they are obviously unnecessary and not in the critical startup path. Correctness before optimization and all that. Syllable is already Fast Enough on most machines. Anyway, after my Windows woes, which thankfully did not involve the dreaded registry, I was thinking that the Windows registry is actually a fairly useful concept to have available to third parties as an abstraction for storing key/value pairs in a simple hierarchy that can be browsed and edited by a knowledgeable user. You may have gripes with Microsoft's failings in the implementation, but it is a useful concept in these days of plug-and-play devices, bluetooth discovery, etc., not to mention tracking shared dll and driver installations and a whole set of software configuration options. It's the over-use of the last one (storing third-party application settings that can get messed up) that has caused the most grief for users over the years. Even Microsoft is admitting they screwed up and is now offering not one but four different APIs for storing application settings in .NET apps: .config files (XML), the registry, "special folders" (I assume this is implemented with NTFS attributes or some sort of hidden file on FAT), and finally "isolated storage" which is like special folders but stored in some special location where the program doesn't have to know where it is. Not much of an improvement, really. :-) In our case we have AFS attributes, and any app is free to use XML or any other format to store settings so, outside of creating an equivalent to the hidden "Application Data" and "Local Settings" folders in Windows (perhaps ".config" if this hasn't already been decided?) in each user's home directory for personal settings, we should be okay on that end. But for communications between the kernel and user programs, we need something a little different. In the Linux world this is communicated through files in the virtual /proc FS (and the newer /sys FS) and the user can get and set flags through sysctl. For the initial startup configuration, simple command-line options, as with Syllable, are sufficient. For the plug-and-play situation and especially for integration between the kernel and the GUI desktop, first there was hotplug, now devfs or the newer user-mode "udev". Under at least Gentoo and probably other distros, you can choose either devfs or udev. At the GUI level, the FreeDesktop project is working on something called d-bus, which appears to be roughly equivalent to our registrar. Anyway, I will look into the capabilities of the registrar as well as read through the d-bus mailing list archives to see how it's being used, and see if perhaps we can begin to use the registrar for communication of information between user processes and the kernel. I would very much like for Syllable to have an equivalent to the Windows task manager (I want to write my own in order to learn the syllable API), and I don't want us to continue passing information in fixed length structures, as we're currently doing in get_system_info(). If we can require init to be running at all times, I don't think it's a big sacrifice to require the registrar to be running as well. Then we can have the equivalent of sysctl, /proc, and udev/d-bus, or equivalent to the Windows registry only better of course. :-) -Jake |
|
From: Arno K. <arn...@ya...> - 2005-02-12 15:46:38
|
Jake Hamby schrieb: > Did Arno Klenke release his kernel patches to anyone in source form? > I have his latest kernel.so and the patches from Dec. 30, but nothing > else. I sent him a private e-mail so I'm sure I'll hear back from him > soon. My syllable installation has crashed so I currently cannot access the patched kernel code that is on another afs partition. Please give me some days to reinstall my system. To the cli()/put_cpu_flags() removal: The functions where I removed this calls are all called from assembler code within syscall.s which already disables the interrupts. So it shouldn´t matter if these calls are present or not. However, I already had a similiar problem when we switched to gcc3. The kernel just locked up while booting. The solution was to move up the put_cpu_flags() call in the TimerInterrupt() function. I did not investigate this problem further but it seem ed that put_cpu_flags() just doesn´t have to be the last call in a function. If I put some useless code after the call then it worked, otherwise not. The current instability of the kernel cannot be caused by these removals because Vanders also reports the same crashes when using the cvs kernel code which still contains these calls. Arno |
|
From: Jake H. <jh...@po...> - 2005-02-12 20:58:21
|
Arno Klenke wrote: > > My syllable installation has crashed so I currently cannot access the > patched kernel code that is on another afs partition. Please give me > some days to reinstall my system. To the cli()/put_cpu_flags() removal: I'm sorry to hear that. One safety measure that I've taken is to perform regular backups of my Syllable partition to DVD-RW using Nero BackItUp from Windows, part of Nero 6 ultra edition. > The current instability of the kernel cannot be caused by these removals > because Vanders also reports the same crashes when using the cvs kernel > code which still contains these calls. That makes sense. I suspect that our problems break down into a couple of categories: 1) 32-bit signed/unsigned comparison issues. The current code is a bit cavalier about doing pointer arithmetic using uint32's and int32's. As we push our 32-bit systems to the limits of memory capacity (4GB or even higher with PAE 36-bit addressing), it's important to be careful here, especially since we know we have bugs on large memory systems. I'm about 90% complete with a fairly major search-and-replace job to convert the kernel to use the standard and more descriptive C99 types, such as uintptr_t and size_t instead of uint32, or the Syllable-specific types like status_t for return values instead of int. This will prepare us for 64-bit support, but will screw up everyone's diffs from the current kernel. Hopefully, by the time your Syllable installation is set up again, you can start hacking from the new, stronger-typed sources. Daniel is probably the only other person who will be impacted by this, but I'll post the diffs here at least a week in advance of committing them to CVS so we can merge our patches. 2) GCC sometimes inlines, sometimes doesn't inline, functions marked "inline". I thought it would be better to write more functions as static inline, rather than as #define macros, but it now seems that some of these functions only work correctly when inlined, e.g. the inline definition of Fork() in init.c. And now it appears there are others that only work correctly when not inlined. Perhaps changing the performance by inlining, even though either version should be correct, is exposing race conditions or other timing issues on SMP systems. 3) Pre- and post-conditions. We should have some standard convention to document pre- and post-conditions for calling a function (such as that interrupts must already be disabled), presumably in the doxygen, as well as using asserts more aggressively to verify these conditions, as well as any loop invariants. This will help us to catch any incorrect assumptions in function usage. -Jake |
|
From: Arno K. <arn...@ya...> - 2005-02-13 13:39:58
|
The kernel patch is now available. It changes the following things: *Fixes the acpi table parsing errors and adds a kernel option to disable the acpi support *Removes the unnecessary cli()/put_cpu_flags() calls *Removes the reflect_irq_to_realmode() call The patch is available here: http://www.liqwyd.com/arno/kernel_patch.zip P.S.: Your code to increase the timer precision has caused a really _huge_ performance drop on my system Arno |
|
From: Jake H. <jh...@po...> - 2005-02-13 23:33:26
|
Arno Klenke wrote: > The kernel patch is now available. It changes the following things: > > *Fixes the acpi table parsing errors and adds a kernel option to disable > the acpi support > *Removes the unnecessary cli()/put_cpu_flags() calls > *Removes the reflect_irq_to_realmode() call Sounds good. I'll check them in soon. > P.S.: Your code to increase the timer precision has caused a really > _huge_ performance drop on my system Interesting. There must be something in the kernel or in user space that is calling get_system_time() or get_real_time() frequently enough for the overhead of disabling interrupts and reading the PIT timer value to be noticable. I'll look into it. Speaking of bad performance, I'm frustrated that there are a couple of threads that chew up a big chunk of CPU time on my system: dbterm: main thread (14%), read thread (7%) media_server_flush: 21.7% ata_cmd_thread: up to 17% for each thread appserver: keyb_thread: 7.1% appserver: input_thread: 2.6% I haven't yet been able to look into why these threads are using so much CPU time, but, except for the ata_cmd_threads, the problems seem to be due to polling and snoozing for events rather than blocking until an event arrives. -Jake |
Thanks for helping keep SourceForge clean.
X