Ingo Hello First thank you for your interest. OFFSCHED is a variant of a proprietary software. it is 4 years old.It is stable. and.. well...this thing works .And it is so simple. SO VERY VERY SIMPLE. ONCE YOU GO OFFLINE YOU NEVER LOOK BACK. OFFSCHED has a full access to many kernel facilities. My software transmits packets, encrypt packets, and reaches network throughput traffic ( 25Gbs), same as pktgen while saturating its 8 SSD disks. My software take statistics of an offloaded processor usage, and unlike OS processors, since I have a full control of the processor, the usage is growing quite linearly. there are no bursts of CPU usage. it remains stable of X% usage even when I transmit 25Gbps. OFFSCHED __oldest__ patch was 4 lines. this how it started. 4 lines of patch and My 2.6.18-8.el5 kernel is suddenly a hard real time kernel. Today, I patch this kernel, build only a bzImage, throw this 2MB bzImage on a server running regular centos/redhat distribution, and caboom, I have a real time server in god-know-where. I do not mess with any driver, i do not mess with initrd. I just fix 4 lines. that all. OFFSCHED is not just for real time. It can monitor the kernel, protect it and do whatever come to mind. please see OFFSCHED-RTOP.pdf. thank you raz On Wed, 2009-08-26 at 21:32 +0200, Ingo aMolnar wrote: > * Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Wed, 26 Aug 2009, Ingo Molnar wrote: > > > > > The thing is, you have cut out (and have not replied to) this > > > crutial bit of what Peter wrote: > > > > > > > > The past year or so you've been whining about the tick latency, > > > > > and I've seen exactly _0_ patches from you slimming down the > > > > > work done in there, even though I pointed out some obvious > > > > > things that could be done. > > > > > > ... which pretty much settles the issue as far as i'm concerned. > > > If you were truly interested in a constructive solution to lower > > > latencies in Linux you should have sent patches already for the > > > low hanging fruits Peter pointed out. > > > > The noise latencies were already reduced in years earlier to the > > mininum (f.e. the work on slab queue cleaning). Certainly more > > could be done there but that misses the point. > > Peter suggested various improvements to the timer tick related > latencies _you_ were complaining about earlier this year. Those > latencies sure were not addressed 'years earlier'. > > If you are unwilling to reduce the very latencies you apparently > cared and complained about then you dont have much real standing to > complain now. > > ( If you on the other hand were approaching this issue with > pragmatism and with intellectual honesty, if you were at the end > of a string of patches that gradually improved latencies but > couldnt get them below a certain threshold, and if scheduler > developers couldnt give you any ideas what else to improve, and > _then_ suggested some other solution, you might have a point. > You are far away from being able to claim that. ) > > Really, it's a straightforward application of Occam's Razor to the > scheduler. We go for the simplest solution first, and try to help > more people first, before going for some specialist hack. > > > The point of the OFFLINE scheduler is to completely eliminate the > > OS disturbances by getting rid of *all* OS processing on some > > cpus. > > > > For some reason scheduler developers seem to be threatened by this > > idea and they go into bizarre lines of arguments to avoid the > > issue. Its simple and doable and the scheduler will still be there > > after we do this. > > If you meant to include me in that summary categorization, i dont > feel 'threatened' by any such patches (why would i? They dont seem > to have sharp teeth nor any apparent poison fangs) - i simply concur > with the reasons Peter listed that it is a technically inferior > solution. > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
