Re: More ULE bugs fixed.

[Bruno Van Den Bossche]

Jeff Roberson <[EMAIL PROTECTED]> wrote:

> On Fri, 31 Oct 2003, Bruno Van Den Bossche wrote:
[...]
> > 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
> > 10001   90.925408
> > 10002   58.897038
> >
> > 200 1   0.735962
> > 200 2   0.676660
> >
> > sched_ule 1.68
> > ---
> > dimension   slaves  time
> > 10001   90.951015
> > 10002   70.402845
> >
> > 200 1   0.743551
> > 200 2   1.900455
> >
> > sched_ule 1.70
> > ---
> > dimension   slaves  time
> > 10001   90.782309
> > 10002   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.

The program can run as a slave or master.  So one should run one master and multiple 
slaves and they all work on a piece of shared memory.  So I've timed the individual 
processes, as the wrapper-script test_pract2 doesn't do more then launch a few 
processes in the background.  I don't think the output of that is very relevant.

Here's the result:

sched_4bsd 1.26

10001
master: 49.172u 0.187s 2:21.54 34.8% 15+10182k 0+0io 0pf+0w 5962c/65w
slave : 90.326u 0.250s 1:30.75 99.8% 15+168k 0+0io 0pf+0w 9156c/35w

10002
master: 49.113u 0.226s 1:49.94 44.8% 15+10181k 0+0io 0pf+0w 5942c/63w
slave1: 55.211u 0.326s 0:59.11 93.9% 15+166k 0+0io 0pf+0w 11129c/2224w
slave2: 54.897u 0.363s 0:58.62 94.2% 15+167k 0+0io 0pf+0w 7111c/6129w

200 1
master: 0.377u 0.007s 0:02.39 15.4% 15+589k 0+0io 0pf+0w 38c/13w
slave : 0.711u 0.031s 0:00.74 100.0% 15+169k 0+0io 0pf+0w 85c/1w

200 2
master: 0.376u 0.007s 0:02.87 12.8% 16+602k 0+0io 0pf+0w 41c/11w
slave1: 0.388u 0.006s 0:01.03 36.8% 18+201k 0+0io 0pf+0w 1245c/408w
slave2: 0.345u 0.038s 0:00.68 54.4% 34+158k 0+0io 0pf+0w 432c/1215w


sched_ule 1.75

10001
master: 49.097u 0.163s 2:21.32 34.8% 15+10186k 0+0io 0pf+0w 6197c/163w
slave : 90.157u 0.398s 1:30.82 99.6% 15+168k 0+0io 0pf+0w 11568c/49w

10002
master: 49.132u 0.164s 1:48.15 45.5% 15+10155k 0+0io 0pf+0w 6517c/276w
slave1: 55.634u 0.406s 0:57.52 97.4% 15+169k 0+0io 0pf+0w 12745c/9628w
slave2: 55.416u 0.391s 0:57.13 97.6% 15+168k 0+0io 0pf+0w 12448c/10063w

200 1
master: 0.369u 0.016s 0:02.52 14.6% 15+577k 0+0io 0pf+0w 92c/35w
slave : 0.690u 0.054s 0:00.74 100.0% 15+171k 0+0io 0pf+0w 147c/13w

200 2
master: 0.376u 0.007s 0:02.47 14.9% 15+589k 0+0io 0pf+0w 87c/21w
slave1: 0.331u 0.023s 0:00.70 50.0% 15+173k 0+0io 0pf+0w 466c/2135w
slave2: 0.304u 0.040s 0:00.39 87.1% 15+166k 0+0io 0pf+0w 412c/2119w

> >
> > [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

This fortune is inoperative.  Please try another.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: More ULE bugs fixed.

[Bruno Van Den Bossche]

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 real59.35 user41.32 sys
> > > >   341.82 real   307.38 user69.01 sys
> > > > SCHED_ULE-today, run immediately after booting:
> > > >41.51 real 7.97 user 6.42 sys
> > > >   306.64 real59.66 user40.68 sys
> > > >   346.48 real   305.54 user69.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 real58.33 user43.61 sys
> > > >   291.59 real   308.48 user72.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 real60.97 user34.63 sys
> > > >   390.68 real   310.78 user60.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
10001   90.925408
10002   58.897038

200 1   0.735962
200 2   0.676660

sched_ule 1.68
---
dimension   slaves  time
10001   90.951015
10002   70.402845

200 1   0.743551
200 2   1.900455

sched_ule 1.70
---
dimension   slaves  time
10001   90.782309
10002   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!

[1] 
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]"

Re: ATA broken as of yesterday?

[Bruno Van Den Bossche]

On Thu, 9 Oct 2003 14:36:12 +0200
Gabriel Ambuehl <[EMAIL PROTECTED]> wrote:

> A machine I had recompiled with a CVSUP as of yesterday (and again
> today, to no avail) can't mount root from a HPT370 (/dev/ar0s1a)
> RAID 1 array anymore, with the saved old kernel (two weeks or so I
> think) it boots without any trouble.

I've got the same controller onboard and just cvsupped and rebuild world
and kernel and everyting seems to be working fine.  I don't have my
root-partition on it and it's configured for striping instead of RAID 1.

atapci1:  port
0xcc00-0xccff,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07
irq 9 at device 14.0 on pci0

-- 
Bruno

The cow is nothing but a machine with makes grass fit for us people
to eat. -- John McNulty
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: SMP & CPU_SUSP_HLT

[Bruno Van Den Bossche]

On Sat, 21 Jun 2003 02:47:42 +0100 (BST)
RMH <[EMAIL PROTECTED]> wrote:

> Hello gentlemen,
> 
> it seems CPU_SUSP_HLT does nothing for SMP kernels.
> 
> i386/i386/machdep.c:
> 
> #ifdef SMP
> static int  cpu_idle_hlt = 0;
> #else
> static int  cpu_idle_hlt = 1;
> #endif
> 
> It's noted that when enabled it will result in about 4.2%
> loss in performance while doing buildworld. I haven't
> checked with that, but I tested single-threaded applications
> to suffer for about 2%, what shouldn't be a big difference.
> 
> Beyond power consumption, suspend on HLT may solve some
> overheating issues common for multiprocessor systems. At
> least, it does so in my case.
> 
> I suggest to remove #ifdef SMP, and place a warning into
> NOTES. Let people decide.

People can decide :-)
You can set 'machdep.cpu_idle_hlt: 1' with sysctl.  This will enable the
hlt's for you.  On single cpu-systems this is set by default.  On
SMP-systems it isn't, because of the "loss" in performance you already
mentioned.

-- 
Bruno

Weinberg's Principle: An expert is a person who avoids the small
errors while sweeping on to the grand fallacy.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fatal trap on RELENG_5_1 SMP

[Bruno Van Den Bossche]

On Sun, 1 Jun 2003 21:14:01 +0200 (CEST)
Magnus J <[EMAIL PROTECTED]> wrote:

> Hello
> 
> 
> I've rebuilt the kernel with these debug-options, and now I'm
> having difficulty reproducing the problem. That was not an issue
> before. Everytime I did 'shutdown', it crashed.

(Un)fortunately(?) it still crashes on my box.  Dual p3 on an abit
motherboard.

I recompiled my kernel with the following options uncommented.  (Hope
that's enough)
makeoptions DEBUG=-g
options DDB

I managed to get a dump and this is what it says.  (pasted below)
If there's more feedback needed, I'll try to provide it.  Just point me
in the right direction on how to get the info you need :-)

Thx.


Start of gdb output

[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOISY # gdb -k
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-undermydesk-freebsd".
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) exec-file /home/kernel
(kgdb) core-file /home/vmcore.0
panic: from debugger
panic messages:
---
Fatal trap 1: privileged instruction fault while in kernel mode
cpuid = 1; lapic.id = 0100
instruction pointer = 0x8:0xd68d1d0e
stack pointer   = 0x10:0xd68d1cec
frame pointer   = 0x10:0x8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 11 (idle: cpu1)

Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address   = 0xc
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc033ff00
stack pointer   = 0x10:0xd68d19f4
frame pointer   = 0x10:0xd68d19f8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu1)
panic: from debugger
cpuid = 1; lapic.id = 0100


Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 1; lapic.id = 0100
instruction pointer = 0x8:0xc03400a5
stack pointer   = 0x10:0xd68d1a98
frame pointer   = 0x10:0xd68d1aa4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 11 (idle: cpu1)
panic: from debugger
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 1m5s
Dumping 511 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_emu10k1.ko...done.
Loaded symbols for /boot/kernel/snd_emu10k1.ko
Reading symbols from
/usr/obj/usr/src/sys/NOISY/modules/usr/src/sys/modules/acpi/acpi.ko.deb
ug...done.
Loaded symbols for
/usr/obj/usr/src/sys/NOISY/modules/usr/src/sys/modules/acpi/acpi.ko.deb
ug
Reading symbols from
/usr/obj/usr/src/sys/NOISY/modules/usr/src/sys/modules/linprocfs/linpro
cfs.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/NOISY/modules/usr/src/sys/modules/linprocfs/linpro
cfs.ko.debug
Reading symbols from
/usr/obj/usr/src/sys/NOISY/modules/usr/src/sys/modules/linux/linux.ko.d
ebug...done.
Loaded symbols for
/usr/obj/usr/src/sys/NOISY/modules/usr/src/sys/modules/linux/linux.ko.d
ebug
Reading symbols from /boot/kernel/daemon_saver.ko...done.
Loaded symbols for /boot/kernel/daemon_saver.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
238 dumping++;
(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:238
#1  0xc020b8d8 in boot (howto=260) at
#/usr/src/sys/kern/kern_shutdown.c:370 2  0xc020bc3f in panic () at
#/usr/src/sys/kern/kern_shutdown.c:543 3  0xc014a2b2 in db_panic () at
#/usr/src/sys/ddb/db_command.c:448 4  0xc014a232 in db_command
#(last_cmdp=0xc03bb5c0, cmd_table=0x0, aux_cmd_tablep=0xc03b4a38,
#aux_cmd_tablep_end=0xc03b4a3c) at /usr/src/sys/ddb/db_command.c:346 5 
#0xc014a346 in db_command_loop () at /usr/src/sys/ddb/db_command.c:470 6
# 0xc014d0ca in db_trap (type=1, code=0) at
# /usr/src/sys/ddb/db_trap.c:72
#7  0xc033fda4 in kdb_trap (type=1, code=0, regs=0xd68d1cac) at
#/usr/src/sys/i386/i386/db_interface.c:170 8  0xc03594e2 in trap_fatal
#(frame=0xd68d1cac, eva=0) at /usr/src/sys/i386/i386/trap.c:829 9 
#0xc0358fa2 in trap (frame=
  {tf_fs = -4194280, tf_es = 16, tf_ds = -1051590640, tf_edi = 0,
tf_esi = -1051588528, tf_ebp = 8, tf_isp = -695395112, tf_ebx =
-1051591872, tf_edx = -1069558912, tf_ecx = 0, tf_eax = 29

Atapicam-error when dma is not turned on

[Bruno Van Den Bossche]

Hi,

Since I upgraded to 5.0-Release the cam-stuff acted a bit weird.
During the boot-proces, right after the SCSI-bus reset it gives these messages:

(probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe1:ata0:0:1:0): CAM Status: SCSI Status Error
(probe1:ata0:0:1:0): SCSI Status: Check Condition
(probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0
(probe1:ata0:0:1:0): Data phase error
(probe1:ata0:0:1:0): Retrying Command (per Sense Data)
(probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe1:ata0:0:1:0): CAM Status: SCSI Status Error
(probe1:ata0:0:1:0): SCSI Status: Check Condition
(probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0
(probe1:ata0:0:1:0): Data phase error
(probe1:ata0:0:1:0): Retrying Command (per Sense Data)
(probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe1:ata0:0:1:0): CAM Status: SCSI Status Error
(probe1:ata0:0:1:0): SCSI Status: Check Condition
(probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0
(probe1:ata0:0:1:0): Data phase error
(probe1:ata0:0:1:0): Retrying Command (per Sense Data)
(probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe1:ata0:0:1:0): CAM Status: SCSI Status Error
(probe1:ata0:0:1:0): SCSI Status: Check Condition
(probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0
(probe1:ata0:0:1:0): Data phase error
(probe1:ata0:0:1:0): Retrying Command (per Sense Data)
(probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 
(probe1:ata0:0:1:0): CAM Status: SCSI Status Error
(probe1:ata0:0:1:0): SCSI Status: Check Condition
(probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0
(probe1:ata0:0:1:0): Data phase error
(probe1:ata0:0:1:0): Retries Exhausted
(probe1:ata0:0:1:0): INQUIRY. CDB: 12 0 0 0 5f 0 
(probe1:ata0:0:1:0): CAM Status: SCSI Status Error
(probe1:ata0:0:1:0): SCSI Status: Check Condition
(probe1:ata0:0:1:0): ABORTED COMMAND asc:4b,0
(probe1:ata0:0:1:0): Data phase error
(probe1:ata0:0:1:0): Retrying Command (per Sense Data)

My system is overclocked, and the error doesn't appear at boot-time when I run it at 
default speed.  But it still gives me some trouble once running.  For example 
'cdrecord -scanbus' tends to hang.  Not every time, but sometimes it does.  And it can 
be reproduced by executing that command rapidly a few times.  After that I can't kill 
it anymore.  Not even with kill -9.

If dma for atapi-devices is turned on, no problems arise, and everyting seems to be 
working fine.

The motherboard is an Abit-VP6 and the drive that's giving me trouble is a Compaq 
dvd-drive, but it has been flashed with Creative-firmware (to make it region-free).

The output of 'camcontrol devlist' is:
  at scbus0 target 5 lun 0 (pass0,cd0)
 at scbus1 target 0 lun 0 (pass1,da0)
  at scbus1 target 1 lun 0 (pass2,da1)
at scbus2 target 0 lun 0 (pass3,cd1)
 at scbus2 target 1 lun 0 (pass4,cd2)

current version of OS:
[EMAIL PROTECTED]:~ > uname -a
FreeBSD Noisy.localhost.localdomain 5.0-RELEASE-p3 FreeBSD 5.0-RELEASE-p3 #0: Mon Feb 
24 16:01:23 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOISY5  i386

The full dmesg-output, kernel-config can be found at 


As I said, everything seems to be working fine with dma turned on and I haven't 
encountered any problems so far.  Maybe (/probably?) it just is the hardware, but I 
don't really have the spare hardware to test.  But the problem never occured while I 
was using 4.7
So I figured I should at least mention the problem on this list.

If I need to do some more tests or supply more info, I'll be glad to (try and) help.

Thanks.

-- 
Bruno

The soul would have no rainbow had the eyes no tears.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message