Jeff Roberson wrote:
On Mon, 3 Nov 2003, Eirik Oeverby wrote:
Hi,
Just recompiled yesterday, running sched_ule.c 1.75. It seems to have
re-introduced the bogus mouse events I talked about earlier, after a
period of having no problems with it. The change happened between 1.69
and 1.75, and there's also the occational glitch in keyboard input.
How unfortunate, it seems to have fixed other problems. Can you describe
the mouse problem? Is it jittery constantly or only under load? Or are
you having other problems? Have you tried reverting to SCHED_4BSD? What
window manager do you run?
The problem is two parts: The mouse tends to 'lock up' for brief moments
when the system is under load, in particular during heavy UI operations
or when doing compile jobs and such.
The second part of the problem is related, and is manifested by the
mouse actually making movements I never asked it to make. It's almost as
if messages passed from the mouse (PS/2 type) through the kernel are
being corrupted or lost - moving the mouse slowly in one direction will
suddenly make it jump half across the screen and continue. Also it will
quite often produce bogus clicks and drags, i.e. I'll be moving the
mouse across the screen and suddenly it grabs something and doesn't let
go - as if it got a MouseRightDown event but no MouseRightRelease event
(or whatever they are called in the world you are in - I'm coming from
OS/2 and other obscure platforms ;).
The second problem usually follows the first - it's more likely to
happen when the system is under some kind of load. Heavy window
repainting/updating (Mozilla Thunderbird is a prime example, but other
apps can be just as guilty), compile jobs, VMWare going crazy with the
CPU, heavy disk/network I/O .. Anything that places load on the
system/kernel can cause this.
Running with SCHED_4BSD completely solves these problems, and the bogus
mouse event problems did NOT appear with sched_ule 1.69 (which is the
last one I tried before 1.75). It did appear with ~1.50 and thereabouts
though (as reported earlier in this thread).
I'm currently running WindowMaker as window manager, but the problem
also exists in Gnome and xfce4. Gnome is more likely to exhibit the
problem even during low system loads, given that it's more violent UI-wise.
You are right though, the later sched_ule revisions DO seem to be better
in many other respects - overall performance 'feels' better (atleast in
console mode). The mouse issues makes X kinda hard to use though.
Btw you might be interested in knowing that the keyboard from time to
time shows what I think is bogus input aswell - I have a consistently
higher rate of failure when typing with sched_ule 1.75 than I had with
1.69, and it definitely feels as if keystrokes are getting lost or
repeated when they shouldn't be. Not often, had two or three
'suspicious' typos while writing this message, and I am reluctant to say
it's a definite kernel issue, because I'm nowhere near a perfect typist
- but it is nevertheless worth noting and might even be worth looking
into. Might there be a connection between this and the mouse issues?
Thanks,
/Eirik
Thanks for the report.
Cheers,
Jeff
If you need me to do anything to track this down, let me know. I am, and
have always been, running with moused, on a uniprocessor box (ThinkPad
T21 1ghz p3).
Best regards,
/Eirik
Jeff Roberson wrote:
On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote:
Jeff Roberson <[EMAIL PROTECTED]> wrote:
On Wed, 29 Oct 2003, Jeff Roberson wrote:
On Thu, 30 Oct 2003, Bruce Evans wrote:
Test for scheduling buildworlds:
cd /usr/src/usr.bin
for i in obj depend all
do
MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i
done >/tmp/zqz 2>&1
(Run this with an empty /somewhere/obj. The all stage doesn't
quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz
CPU, with/usr (including /usr/src) nfs-mounted (with 100 Mbps
ethernet and a reasonably fast server) and /somewhere/obj
ufs1-mounted (on a fairly slow disk; no soft-updates), this
gives the following times:
SCHED_ULE-yesterday, with not so careful setup:
40.37 real 8.26 user 6.26 sys
278.90 real 59.35 user 41.32 sys
341.82 real 307.38 user 69.01 sys
SCHED_ULE-today, run immediately after booting:
41.51 real 7.97 user 6.42 sys
306.64 real 59.66 user 40.68 sys
346.48 real 305.54 user 69.97 sys
SCHED_4BSD-yesterday, with not so careful setup:
[same as today except the depend step was 10 seconds
slower (real)]
SCHED_4BSD-today, run immediately after booting:
18.89 real 8.01 user 6.66 sys
128.17 real 58.33 user 43.61 sys
291.59 real 308.48 user 72.33 sys
SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz
CPU) with
many local changes and not so careful setup:
17.39 real 8.28 user 5.49 sys
130.51 real 60.97 user 34.63 sys
390.68 real 310.78 user 60.55 sys
Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for
the obj and depend stages. These stages have little
parallelism. SCHED_ULE was only 19% slower for the all stage.
...
I reran this with -current (sched_ule.c 1.68, etc.). Result: no
significant change. However, with a UP kernel there was no
significant difference between the times for SCHED_ULE and
SCHED_4BSD.
There was a significant difference on UP until last week. I'm
working on SMP now. I have some patches but they aren't quite ready
yet.
I have commited my SMP fixes. I would appreciate it if you could post
update results. ULE now outperforms 4BSD in a single threaded kernel
compile and performs almost identically in a 16 way make. I still
have a few more things that I can do to improve the situation. I
would expect ULE to pull further ahead in the months to come.
I recently had to complete a little piece of software in a course on
parallel computing. I've put it online[1] (we only had to write the
pract2.cpp file). It calculates the inverse of a Vandermonde matrix and
allows you to spawn multiple slave-processes who each perform a part of
the work. Everything happens in memory so
I've used it lately to test the different changes you made to
sched_ule.c and these last fixes do improve the performance on my dual
p3 machine a lot.
Here are the results of my (very limited tests) :
sched4bsd
---
dimension slaves time
1000 1 90.925408
1000 2 58.897038
200 1 0.735962
200 2 0.676660
sched_ule 1.68
---
dimension slaves time
1000 1 90.951015
1000 2 70.402845
200 1 0.743551
200 2 1.900455
sched_ule 1.70
---
dimension slaves time
1000 1 90.782309
1000 2 57.207351
200 1 0.739998
200 2 0.383545
I'm not really sure if this is very relevant to you, but from the
end-user point of view (me :-)) this does means something.
Thanks!
I welcome the feedback, positive or negative, as it helps me improve
things. Thanks for the report! Could you run this again under 4bsd and
ULE with the following in your .cshrc:
set time= ( 5 "%Uu %Ss %E %P %X+%Dk %I+%Oio %Fpf+%Ww %cc/%ww" )
And then time ./testpract 200 2, etc. This will give me a few hints about
what's impacting your performance.
Thanks!
Jeff
[1] <http://users.pandora.be/bomberboy/mptest/final.tar.bz2>
It can be used by running testpract2 with two arguments, the dimension
of the matrix and the number of slaves. example './testpract2 200 2'
will create a matrix with dimension 200 and 2 slaves.
--
Bruno
... And then there's the guy who bought 20,000 bras, cut them in half,
and sold 40,000 yamalchas with chin straps....
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
