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
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
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
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 what's going on
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
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
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
> > > >
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
precisely
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 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 exactly as I'd
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 perfectly bound
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
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 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 a
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 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
> > >
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
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 jerkiness
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
general, looking
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.
What
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
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 your
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 from using it
26 matches
Mail list logo
