| |||||||||||||
|
| |||||||||||||
Followups: performance counters, ksplice, and fsnotifyFollowups: performance counters, ksplice, and fsnotifyPosted Dec 18, 2008 5:18 UTC (Thu) by deater (subscriber, #11746)Parent article: Followups: performance counters, ksplice, and fsnotify
Ingo's performance counter infrastructure is a bit pointless. All it does is distract from the actual performance counter implementations that are trying to be merged (admittedly those partially sat outside of the kernel a bit too long).
If Ingo ever addresses the shortcomings brought up on the linux-kernel list (he hasn't) or ever tries to implement things on a machine that isn't a Core 2 Duo machine (most notably, Pentium 4 or PowerPC) he'll find out that things get complicated quickly. And the kernel is not the place for these complications.
It's a big mess, and a big frustration to those of us who use performance counters regularly and have to look forward to the prospect of patching our kernels by hand for years to come because an inferior infrastructure useful more-or-less only to Ingo gets merged.
(Log in to post comments)
Followups: performance counters, ksplice, and fsnotify Posted Dec 18, 2008 15:05 UTC (Thu) by niner (subscriber, #26151) [Link]
I wonder where this sentiment that hardware specific stuff doesn't belong
into the kernel comes from. I thought one of the kernel's main purposes was to abstract the hardware and hide it from user space. Why then put hardware specific stuff into user space libraries instead of the kernel?
Followups: performance counters, ksplice, and fsnotify Posted Dec 19, 2008 5:02 UTC (Fri) by deater (subscriber, #11746) [Link] I wonder where this sentiment that hardware specific stuff doesn't belong into the kernel comes from. I thought one of the kernel's main purposes was to abstract the hardware and hide it from user space. Why then put hardware specific stuff into user space libraries instead of the kernel?The kernel should abstract the hardware, but in as minimal way as possible. With performance counters this means that the kernel should enable starting and stopping of monitoring, enforce some sanity checks, and provide user-space with a common way to set up events. What it does *not* mean is including 200k of library code that maps meaningful textual names to the numeric counter identifiers, or including all the subtle limitations of the counters (not all counters can count all events, not all counters are available on all steppings of a CPU, etc). Putting that all into the kernel would definitely be a losing proposition. Perfmon does it from userspace. Ingo's method would have it all in the kernel. This is a similar argument about whether video4linux should include format conversions into the kernel or not. It's important to know what the correct level of abstraction for your interface is.
Followups: performance counters, ksplice, and fsnotify Posted Dec 21, 2008 12:05 UTC (Sun) by Ze (subscriber, #54182) [Link]
>Putting that all into the kernel would definitely be a losing proposition. Perfmon does it from userspace. Ingo's method would have it all in the kernel.
>This is a similar argument about whether video4linux should include format conversions into the kernel or not. It seems to me that this is an argument in favour of a microkernel approach.
I mean we've already got loadable kernel modules , fuse , and a move to push usb drivers out of kernel space into libusb.
Personally I can see the day when someone leverages the kernel driver model code but puts it in a kernel based around a microkernel.
|
|
||||||||||||