Jörn Nettingsmeier wrote:
>
> andrew, you're my hero.
That's what my daughter says - you're in good company :)
> thanks for the kernel-howto !
>
> Andrew Morton wrote:
> >
> > This is pretty much "it". I ran it for six hours on a "typical
> > desktop", running X, netscape, Apache, StarOffice, imapd, ftpd,
> > sendmail, fetchmail, etc and the worst-case latency was 3-4 millisecs:
> >
> > 0-1 millisecs: 99.999%
> > 1-2 0.0004%
> > 2-3 0.00009%
> > 3-4 0.0005%
> >
>
> yeah. this is absolutely good enough for our current needs.
> (except if somebody is being creative again :)
test, test...
> > Yes, there are probably still ways it can be tripped up, but there's no
> > point in addressing these unless someone can demonstrate a problem which
> > doesn't have an acceptable workaround. I can't, apart from waking up
> > kswapd.
> >
> > There are now nine rescheduling points which handle:
> >
> > sys_unlink()
> > sys_msync()
> > sys_read()
> > sys_madvise(MADV_DONTNEED)
> > sys_write()
> > sys_sync()
> > sys_munmap()
> > sys_exit() (__exit_mm)
>
> not that i understand any details, but this should be far from
> "random hacks all over the kernel".
I agree. I'd be offended if these didn't make it into the mainstream.
I'm currently running exhaustive performance testing to see if it has an
impact.
If a fight breaks out over this the backup position is to make it
optional at runtime, so instead of
if (current->need_resched)
schedule()
it becomes
if (some_flag && current->need_resched)
schedule();
where `some_flag' is controlled via /proc or a sysctl. This shouldn't
be necessary though.
> > Filesystems other than ext2 and NFS client have not been tested.
>
> oh-oh. i have reiserfs on /usr and /var (suse bigot !).
> i will try it anyway. did you patch any ext2-specific stuff, or is
> it all in common code on the VFS layer ? (excuse the dumbness of my
> question, but even if i UTSL, it wouldn't help much !)
No, I didn't touch ext2. There _may_ be a need to but it's unlikely.
reiserfs is probably OK, but I haven't tried it.
