Re: [gentoo-user] Re: Kon Colivas is working again on a new scheduler for Desktop/Multimedia/Gaming PCs

[Volker Armin Hemmann <volkerarmin@googlemail.com>]

On Sonntag 06 September 2009, Nikos Chantziaras wrote:
> On 09/06/2009 03:50 AM, Volker Armin Hemmann wrote:
> > On Sonntag 06 September 2009, Nikos Chantziaras wrote:
> >> On 09/06/2009 02:26 AM, Volker Armin Hemmann wrote:
> >>> On Sonntag 06 September 2009, Nikos Chantziaras wrote:
> >>>> On 09/06/2009 01:48 AM, Volker Armin Hemmann wrote:
> >>>>> On Samstag 05 September 2009, Nikos Chantziaras wrote:
> >>>>>> On 09/05/2009 05:59 PM, Volker Armin Hemmann wrote:
> >>>>>>>> 1000 Hz timer freq
> >>>>>>>
> >>>>>>> change that to 300
> >>>>>>>
> >>>>>>>> Did you mean tickless system with "noticks"? I have this enabled
> >>>>>>>> ATM
> >>>>>>>
> >>>>>>> deactivate that.
> >>>>>>
> >>>>>> Even with that, there still are problems.  With composite enabled,
> >>>>>> move an mplayer window around and see how the video starts to skip
> >>>>>> big amounts of frames at the moment you start moving and when you
> >>>>>> "drop" it again.  The compositor takes away CPU time and mplayer
> >>>>>> starves for a short time.  BFS solves this.
> >>>>>
> >>>>> nope. No drops. vlc, xine, mplayer. At least no visible drop - and
> >>>>> none of the three is complaining.
> >>>>
> >>>> Well, not here.
> >>>>
> >>>>> But there is a pro-tip: use a non-broken X. aka one with
> >>>>>
> >>>>> fedora_dont_backfill_bg_none.patch
> >>>>
> >>>> I do use that.
> >>>>
> >>>>>> Also, have you considered that you got it all backwards?  The kernel
> >>>>>> configuration tells you that for lower latencies, you should use
> >>>>>> 1000Hz and PREEMPT.  It even says "Desktop" right there.  Why should
> >>>>>> I take your word over that of the kernel devs who actually wrote
> >>>>>> that code?
> >>>>>
> >>>>> low latency means bad throughput and that hurts IO.
> >>>>
> >>>> GUI stalls still happen with high latency settings.  Doesn't seem to
> >>>> matter; 300Hz, 1000Hz, tickless or not, PREEMPT or not, multicore
> >>>> scheduler or not, all the same.  GUI stalls during load.  It only goes
> >>>> away with Con's scheduler.
> >>>
> >>> attached is my config. Because I don't need Con's scheduler for a nice
> >>> desktop experience.
> >>
> >> Good for you.  I'm attaching mine.
> >>
> >>> What am I doing wrong?
> >>
> >> I don't know.  Maybe it's just that you're as perceptive as the average
> >> turtle.
> >
> > and maybe you should decrapify your config a bit? Namespaces? Seccomp?
> > Process accounting? no compat vdso?
> >
> > You really hate performance, do you?
> 
> On another note:
> 
> "Say N here if you are running a sufficiently recent glibc version
> (2.3.3 or later), to remove the high-mapped VDSO mapping and to
> exclusively use the randomized VDSO."
> 
> And digging turned up that it saves about 6-10 instructions per syscall
> but limits the flexibility.  This may be a significant improvement for
> intensive-IO processes.
> 
> And about process accounting:
> 
> "This is generally a good idea, so say Y."

yeah, if you are in a bean counter environment. Nobody else needs it.

> 
> Well, I said Y.
> 
> And on seccomp:
> 
> "... If unsure, say Y. Only embedded should say N here."
> 
> Well, guess what?  I'm not on "embedded".

and seccomp is only used by a single project by Andrea Arcangeli. Nobody else 
uses it. He also was the submitter of that feature.