Antonio Vargas wrote:
IIRC, about 2 or three years ago (or maybe on the 2.6.10 timeframe),
there was a patch which managed to pass the interactive from one app
to another when there was a pipe or udp connection between them. This
meant that a marked-as-interactive xterm would, when blocked waiti
Op Sunday 18 March 2007, schreef Con Kolivas:
> On Monday 12 March 2007 22:26, Al Boldi wrote:
> > Con Kolivas wrote:
> > > On Monday 12 March 2007 15:42, Al Boldi wrote:
> > > > Con Kolivas wrote:
> > > > > On Monday 12 March 2007 08:52, Con Kolivas wrote:
> > > > > > And thank you! I think I know
On 3/12/07, jos poortvliet <[EMAIL PROTECTED]> wrote:
Op Monday 12 March 2007, schreef Con Kolivas:
> On Tuesday 13 March 2007 01:14, Al Boldi wrote:
> > Con Kolivas wrote:
> > > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > > one runs 6-7ms and then one larger p
Op Monday 12 March 2007, schreef Con Kolivas:
> On Tuesday 13 March 2007 01:14, Al Boldi wrote:
> > Con Kolivas wrote:
> > > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > > one runs 6-7ms and then one larger perfectly bound expiration
> > > > > amount. Basically ex
On 3/12/07, jos poortvliet <[EMAIL PROTECTED]> wrote:
Op Monday 12 March 2007, schreef Al Boldi:
>
> It only takes one negatively nice'd proc to affect X adversely.
goes faster than ever)? Or is this really the scheduler's fault?
Take this with a grain of salt, but, I don't think this is the
Op Monday 12 March 2007, schreef Al Boldi:
> Con Kolivas wrote:
> > > > The higher priority one always get 6-7ms whereas the lower priority
> > > > one runs 6-7ms and then one larger perfectly bound expiration amount.
> > > > Basically exactly as I'd expect. The higher priority task gets
> > > > pr
Xavier Bestel wrote:
> On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> > Hah I just wish gears would go away. If I get hardware where it runs at
> > just the right speed it looks like it doesn't move at all. On other
> > hardware the wheels go backwards and forwards where the screen refresh
On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> Hah I just wish gears would go away. If I get hardware where it runs at just
> the right speed it looks like it doesn't move at all. On other hardware the
> wheels go backwards and forwards where the screen refresh rate is just
> perfectly
On Tuesday 06 March 2007 05:23, Al Boldi wrote:
> Con Kolivas wrote:
> > Gears just isn't an interactive task and just about anything but gears
> > would be a better test case since its behaviour varies wildly under
> > different combinations of graphics cards, memory bandwidth, cpu and so
> > on.
On Monday 05 March 2007 22:59, Al Boldi wrote:
> Markus Törnqvist wrote:
> > On Mon, Mar 05, 2007 at 08:34:45AM +0300, Al Boldi wrote:
> > >Ok, gears is smooth when you run "make -j4", but with "nice make -j4",
> > > gears becomes bursty. This looks like a problem with nice-levels. In
> > > gener
Markus Törnqvist wrote:
> On Mon, Mar 05, 2007 at 08:34:45AM +0300, Al Boldi wrote:
> >Ok, gears is smooth when you run "make -j4", but with "nice make -j4",
> > gears becomes bursty. This looks like a problem with nice-levels. In
> > general, looking subjectively at top d.1, procs appear to show
Op Monday 05 March 2007, schreef Willy Tarreau:
> On Mon, Mar 05, 2007 at 08:49:29AM +1100, Con Kolivas wrote:
> (...)
>
> > > That's just what it did, but when you "nice make -j4", things (gears)
> > > start to stutter. Is that due to the staircase?
> >
> > gears isn't an interactive task. Apart
Op Sunday 04 March 2007, schreef Willy Tarreau:
> Hi Con !
> > This was designed to be robust for any application since linux demands a
> > general purpose scheduler design, while preserving interactivity, instead
> > of optimising for one particular end use.
>
> Well, I haven't tested it yet, but
13 matches
Mail list logo
