Re: Can't buildworld since Clang update
It works.make buildworld works ok now.Thinks Dimitry Andric. On Fri, Feb 25, 2011 at 5:54 AM, Dimitry Andric wrote: > On 2011-02-24 08:26, datastream datastream.freecity wrote: > >> I removed /etc/src.conf.binutils is 2.15. >> > ... > > Ok, I managed to reproduce your error, on an old snapshot with clang 2.8 > and binutils 2.15. It turns out it is caused by an upstream change, > which was intended to work around problems in the configure scripts of > some ports. > > Unfortunately, it also has the side effect of sometimes picking the > wrong libraries to link with, which can lead to the error you have seen. > > I have committed a fix for this in r219011; can you please update to at > least that revision, blow away your /usr/obj just to be sure, and try to > rebuild? It should now work properly. > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: BSD iconv coming to the base system with default off
Anonymous writes in "[CFT] BSDL iconv in base system":
> I guess gettext hanging is due to ABI incompatibility, too.
>
> $ cat foo.po
> msgid ""
> msgstr ""
> "Content-Type: text/plain; charset=UTF-8\n"
> "Content-Transfer-Encoding: 8bit\n"
>
> msgid "don’t"
> msgstr "do not"
>
> $ msgmerge foo.po /dev/null # GNU iconv
> . done.
> msgid ""
> msgstr ""
> "Content-Type: text/plain; charset=UTF-8\n"
> "Content-Transfer-Encoding: 8bit\n"
>
> #~ msgid "don’t"
> #~ msgstr "do not"
>
> $ msgmerge foo.po /dev/null # BSD iconv
> . done.
> msgid ""
> load: 0.10 cmd: msgmerge 65132 [runnable] 2.74r 2.72u 0.00s 23% 2844k
> ^C
> (gdb) bt
> #0 _citrus_iconv_none_iconv_convert (ci=0x80f00f190, in=0x7fff0b40,
> inbytes=0x7fff0b40, out=0x7fff0b48, outbytes=0x7fff0b50, flags=0,
> invalids=0x7fff0aa0) at
> /usr/src/lib/libiconv_modules/iconv_none/citrus_iconv_none.c:119
> len = 1
> e2big = 0
> #1 0x0008064b9142 in _citrus_iconv_convert (cv=0x80f00f190,
> in=0x7fff0b38, inbytes=0x7fff0b40, out=0x7fff0b48,
> outbytes=0x7fff0b50,
> flags=0, nresults=0x7fff0aa0) at citrus_iconv.h:60
> No locals.
> #2 0x0008064b90b2 in libiconv (handle=0x80f00f190, in=0x7fff0b38,
> szin=0x7fff0b40, out=0x7fff0b48, szout=0x7fff0b50)
> at /usr/src/lib/libc/iconv/iconv.c:147
> ret = 0
> err = 0
> #3 0x0008036db20a in wrap (mp=0x80f020400, stream=0x80f0123c0,
> line_prefix=0x0, extra_indent=0, css_class=0x80370a2f0 "msgstr",
> name=0x80370a3a9 "msgstr", value=0x80f01f0b0 "Content-Type: text/plain;
> charset=UTF-8\nContent-Transfer-Encoding: 8bit\n", do_wrap=undecided,
> page_width=79, charset=0x7fff0d80 "UTF-8") at write-po.c:724
> #4 0x0008036dcbdd in message_print (mp=0x80f020400,
> stream=0x80f0123c0, charset=0x7fff0d80 "UTF-8", page_width=79,
> blank_line=false, debug=false)
> at write-po.c:1283
> #5 0x0008036dd736 in msgdomain_list_print_po (mdlp=0x80f0071c0,
> stream=0x80f0123c0, page_width=79, debug=false) at write-po.c:1511
> #6 0x0008036d8859 in msgdomain_list_print (mdlp=0x80f0071c0,
> filename=0x80370a0a6 "standard output", output_syntax=0x40d7b0, force=false,
> debug=false)
> at write-catalog.c:246
> #7 0x00403604 in main (argc=3, argv=0x7fff0ff0) at
> msgmerge.c:463
Above test still hangs as of r219023M with similar trace.
Should I file a PR or bsdiconv isn't supposed to work in such a way?
>
> It's a bit tweaked version, though.
>
> %%
> Index: devel/gettext/Makefile
> ===
> RCS file: /a/.cvsup/ports/devel/gettext/Makefile,v
> retrieving revision 1.87
> diff -u -p -r1.87 Makefile
> --- devel/gettext/Makefile3 Jun 2010 09:46:38 - 1.87
> +++ devel/gettext/Makefile23 Aug 2010 10:04:26 -
> @@ -28,7 +28,7 @@ CONFIGURE_ENV= ACLOCAL="${TRUE}" \
> AUTOHEADER="${TRUE}" \
> MAKEINFO="makeinfo --no-split" \
> CPPFLAGS="-I${LOCALBASE}/include" \
> - LDFLAGS="-L${LOCALBASE}/lib" \
> + LDFLAGS="-L${LOCALBASE}/lib -liconv" \
> EMACS="no"
> CONFIGURE_ARGS= --disable-csharp --disable-threads --disable-openmp \
> --with-included-gettext --with-included-glib \
> @@ -65,6 +65,8 @@ pre-extract:
> .endif
>
> post-patch:
> + @${REINPLACE_CMD} 's/-DENABLE_RELOCATABLE=1//' \
> + ${WRKSRC}/gettext-runtime/intl/Makefile.in
> @${FIND} ${WRKSRC} -name configure -print | ${XARGS} \
> ${REINPLACE_CMD} -e 's|mkdir gmkdir|mkdir|'
> .if defined (NOPORTDOCS)
> %%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Process timing issue
On 22/02/2011, at 2:54, Jerome Flesch wrote: > While investigating a timing issue with one of our program, we found out > something weird: We've written a small test program that just calls > clock_gettime() a lot of times and checks that the time difference between > calls makes sense. In the end, it seems it doesn't always do. > > Calling twice in a row clock_gettime() takes usually less than 1ms. But with > an average load, about 1 time in 20, more than 10ms are spent between > both calls for no apparent reason. According to our tests, when it happens, > the time between both calls can go from few milliseconds to many seconds (our > best score so far is 10 seconds :). Same goes for gettimeofday(). > > To reproduce this issue, we use the small test program joined to this mail > and openssl speed test commands (usually 'openssl speed -elapsed dsa2048'). > It only appears if one of these openssl speed test run on the same core than > our test progam, so we have to start as many openssl instances as there are > cores on the test computer. This sounds like a problem I have trying to read from a FIFO in hardware over USB. Most of the time the libusb poll thread doesn't take very long, but every now and then it takes too long and my FIFO fills up (~75msec). If you do find a solution I would be very interested :) In the end I wrote a kernel driver which read & buffered the data, but I suppose that is not possible for you. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HEADSUP: BSD iconv coming to the base system with default off
Hi Folks, I've got some time again to keep working on iconv. The last time I posted a patch, there were problems with some ports but apart from this it proved to be quite mature, so I decided to commit it to the base system but the default setting will be disabled. It can be enabled by setting the WITH_ICONV knob but whoever does it will take into account that it may break some ports from being built. However, this change will help me with future work and will also help interested people in getting involved in the testing. The rather big changeset is coming soon. Regards, Gabor Kovesdan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
TODOs for suspend/resume (Re: Cosmetic path to bsdinstall)
On Thursday 24 February 2011 04:53 pm, Brandon Gooch wrote: > On Feb 24, 2011, at 2:44 PM, Bruce Cran wrote: > > On Thu, 24 Feb 2011 15:38:15 -0500 > > > > Jung-uk Kim wrote: > >> FYI, I've been using the following hack for a while now: > >> > >> http://people.freebsd.org/~jkim/ada_suspend.diff > > > > Thanks, I'd given up trying to fix this because I was under the > > impression it needed newbus. I'll see if I can get something > > similar committed so at least another part of suspend/resume > > works. > > > > I think someone mentioned there was documentation somewhere that > > was going to be put on the Wiki about what needs done in order to > > get suspend/resume working properly. Does anyone know where that > > might be? > > > > -- > > Bruce Cran > > I'd also be interested in reading about this, as I often field > questions from my colleagues... I am not aware of such documentation. Mostly the problem is in device drivers. Someone should start a list of misbehaving device drivers first if needed. However, it is not easy because several layers are involved, i.e., bus drivers (acpi, isa, pci, usb, ...) and their children (acpi_video, atkbdc, ath, ums...) and we don't know for sure what's to blame. Also, many complaints are related to GPU issues. Currently, we rely on simple VGA registers or VESA BIOS (if vesa.ko is loaded) but many modern GPUs simply don't care about these any more. So, we need GPU-specific drivers (as Linux does it via KMS nowadays). The only workaround for these problems is using X.org with "right" device drivers ATM. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Thursday, February 24, 2011 3:35:51 pm Nathan Whitehorn wrote: > On 02/24/11 14:14, John Baldwin wrote: > > On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: > >> Thanks! I've received basically this patch from a couple people now. I'm > >> going to investigate whether this is a more generic way to get this > >> information (so the list doesn't grow infinitely long), and will commit > >> this if I can't. Having CAM devices be part of newbus would simplify > >> this a very great deal... > > Note that all these disk devices are not CAM devices, so CAM changing to > > use new-bus wouldn't really matter one whit. They do all show up as 'DISK' > > GEOM's however (I also hacked on a GEOM-based libdisk replacement at one > > point, though probably less developed than Marcel's. I used libgeom to > > discover DISK devices.) Given that disk_create() already hooks into GEOM, > > that is probably the right way to discover disks in a generic fashion. > > Right, stepping through that is how I build the list. Adding a device > description to the XML actually seems like a good idea (and maybe the > drive serial number?). Would anyone have any objections to me starting > to go through and do that? I think that would be fine, but I don't think GEOM knows about those properties yet? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Feb 24, 2011, at 2:44 PM, Bruce Cran wrote: > On Thu, 24 Feb 2011 15:38:15 -0500 > Jung-uk Kim wrote: > >> FYI, I've been using the following hack for a while now: >> >> http://people.freebsd.org/~jkim/ada_suspend.diff > > Thanks, I'd given up trying to fix this because I was under the > impression it needed newbus. I'll see if I can get something similar > committed so at least another part of suspend/resume works. > > I think someone mentioned there was documentation somewhere that was > going to be put on the Wiki about what needs done in order to get > suspend/resume working properly. Does anyone know where that might be? > > -- > Bruce Cran > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I'd also be interested in reading about this, as I often field questions from my colleagues... -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't buildworld since Clang update
On 2011-02-24 08:26, datastream datastream.freecity wrote: I removed /etc/src.conf.binutils is 2.15. ... Ok, I managed to reproduce your error, on an old snapshot with clang 2.8 and binutils 2.15. It turns out it is caused by an upstream change, which was intended to work around problems in the configure scripts of some ports. Unfortunately, it also has the side effect of sometimes picking the wrong libraries to link with, which can lead to the error you have seen. I have committed a fix for this in r219011; can you please update to at least that revision, blow away your /usr/obj just to be sure, and try to rebuild? It should now work properly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with a port after clang'ifying
A little more information. Using -O0 or -O1 in CFLAGS the resulting binary works. The default of -O2 crashes, with or without -fno-strict-aliasing. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Thu, 24 Feb 2011 15:38:15 -0500 Jung-uk Kim wrote: > FYI, I've been using the following hack for a while now: > > http://people.freebsd.org/~jkim/ada_suspend.diff Thanks, I'd given up trying to fix this because I was under the impression it needed newbus. I'll see if I can get something similar committed so at least another part of suspend/resume works. I think someone mentioned there was documentation somewhere that was going to be put on the Wiki about what needs done in order to get suspend/resume working properly. Does anyone know where that might be? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Thursday 24 February 2011 03:11 pm, John Baldwin wrote: > On Thursday, February 24, 2011 10:27:59 am Bruce Cran wrote: > > On Thu, 24 Feb 2011 09:00:44 -0600 > > > > Nathan Whitehorn wrote: > > > Having CAM devices be part of newbus would > > > simplify this a very great deal... > > > > It's required if we're ever going to have suspend/resume working > > properly because currently CAM doesn't get a suspend > > notification, so doesn't know to spin-down disks etc. > > The controllers get a suspend notification though (via > device_suspend() hooks that drivers like mpt, etc. could register > for) and could then use that to post a suspend of the associated > buses. That doesn't require CAM to use new-bus though. FYI, I've been using the following hack for a while now: http://people.freebsd.org/~jkim/ada_suspend.diff Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On 02/24/11 14:14, John Baldwin wrote: On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: Thanks! I've received basically this patch from a couple people now. I'm going to investigate whether this is a more generic way to get this information (so the list doesn't grow infinitely long), and will commit this if I can't. Having CAM devices be part of newbus would simplify this a very great deal... Note that all these disk devices are not CAM devices, so CAM changing to use new-bus wouldn't really matter one whit. They do all show up as 'DISK' GEOM's however (I also hacked on a GEOM-based libdisk replacement at one point, though probably less developed than Marcel's. I used libgeom to discover DISK devices.) Given that disk_create() already hooks into GEOM, that is probably the right way to discover disks in a generic fashion. Right, stepping through that is how I build the list. Adding a device description to the XML actually seems like a good idea (and maybe the drive serial number?). Would anyone have any objections to me starting to go through and do that? -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Wed, Feb 23, 2011 at 4:37 AM, Mitya wrote:
> Add usually used RAID controller
>
> --- usr.sbin/bsdinstall/partedit/part_wizard.c.orig 2011-02-19
> 17:22:06.0 +0200
> +++ usr.sbin/bsdinstall/partedit/part_wizard.c 2011-02-21
> 17:20:28.0 +0200
> @@ -122,6 +122,18 @@
> strcat(diskdesc, " ATA Hard Disk");
> else if (strncmp(pp->lg_name, "da", 2) == 0)
> strcat(diskdesc, " SCSI Hard Disk");
> + else if (strncmp(pp->lg_name, "aacd", 4) == 0)
> + strcat(diskdesc, " Adaptec Raid Disk");
> + else if (strncmp(pp->lg_name, "amrd", 4) == 0)
> + strcat(diskdesc, " LSI Raid Disk");
> + else if (strncmp(pp->lg_name, "mfid", 4) == 0)
> + strcat(diskdesc, " LSI Raid Disk");
> + else if (strncmp(pp->lg_name, "mlxd", 4) == 0)
> + strcat(diskdesc, " Mylex Raid Disk");
> + else if (strncmp(pp->lg_name, "twed", 4) == 0)
> + strcat(diskdesc, " 3ware Raid Disk");
> + else if (strncmp(pp->lg_name, "pst", 3) == 0)
> + strcat(diskdesc, " Promise Raid Disk");
> else if (strncmp(pp->lg_name, "md", 2) == 0)
> strcat(diskdesc, " Memory Disk");
> else if (strncmp(pp->lg_name, "cd", 2) == 0) {
You forgot "twad" :).
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Thursday, February 24, 2011 10:27:59 am Bruce Cran wrote: > On Thu, 24 Feb 2011 09:00:44 -0600 > Nathan Whitehorn wrote: > > > Having CAM devices be part of newbus would > > simplify this a very great deal... > > It's required if we're ever going to have suspend/resume working > properly because currently CAM doesn't get a suspend notification, so > doesn't know to spin-down disks etc. The controllers get a suspend notification though (via device_suspend() hooks that drivers like mpt, etc. could register for) and could then use that to post a suspend of the associated buses. That doesn't require CAM to use new-bus though. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Thursday, February 24, 2011 10:00:44 am Nathan Whitehorn wrote: > Thanks! I've received basically this patch from a couple people now. I'm > going to investigate whether this is a more generic way to get this > information (so the list doesn't grow infinitely long), and will commit > this if I can't. Having CAM devices be part of newbus would simplify > this a very great deal... Note that all these disk devices are not CAM devices, so CAM changing to use new-bus wouldn't really matter one whit. They do all show up as 'DISK' GEOM's however (I also hacked on a GEOM-based libdisk replacement at one point, though probably less developed than Marcel's. I used libgeom to discover DISK devices.) Given that disk_create() already hooks into GEOM, that is probably the right way to discover disks in a generic fashion. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Process timing issue
On Thursday, February 24, 2011 12:34:04 pm Andriy Gapon wrote: > on 24/02/2011 16:18 Jerome Flesch said the following: > > Thanks for your explanations. It helped greatly. Using ktrdump and > > schedgraph.py > > and after modifying our test program to set and unset automatically > > debug.ktr.mask, I've been able to get useful information. > > > > First, It made me realize that task switching, with default settings and 2 > > active > > processes, only occurs each 100ms. Knowing that, expecting a latency time > > around > > 100ms was kind of silly :) > > > > Next, it seems most of the latency pikes are due to a process starting or > > waking > > up. For instance, it usually happens when the openssl speed test is started > > ( > > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_start.png > > ) or when pagedaemon wakes up (I forgot to disable the swap and my test > > program > > used too much memory to store the result values ...). I'm not sure why, but > > when > > we start openssl, it is often allowed to run for >= 300ms, even with our > > test > > program set to real time priority. My intuition is that, at first, it's > > considered > > as an interactive process, until the scheduler realizes it's not. But then, > > does > > anyone know why it would take more than 300ms for the scheduler to realize > > that ? > > > > Anyway, by setting kern.sched.interact=5 (so openssl isn't considered as an > > interactive process), kern.sched.slice=3 (to get an high enough scheduling > > resolution), and our program to real-time priority, we got rid of both > > problems. > > I'm just a little bit worried about kern.sched.slice=3. Is there any known > > side > > effect when reducing slices size ? > > > > Also, another issue remain: We were hoping to keep our program with a normal > > priority. However when we set our test program to a normal priority (but > > still an > > higher priority than openssl), both get 50% of the CPU (I guess this is to > > be > > expected), and from time to time we have a "hiccup" in the scheduling: > > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.png > > . Is > > there any way to avoid them ? In other words, is it possible to make sure > > that the > > low priority process never gets more CPU time than the high priority one ? > > The problems that you describe here sound very much like the issues that John > Baldwin has been trying to solve a short while ago. My recollection is that > he > committed some improvements for real time priority processes. Perhaps he'll > have > some additional insights based on his observations and testing. Well, the changes I made to 9 simply made rtprio more important than interactive so that rtprio will always preempt interactive time-sharing threads. I'm not quite sure that this is exactly the same. Note that by default ULE does give interactive processes realtime priority, so that is why openssl would not yield early on during startup. As to why it takes the scheduler 300ms to decide openssl is a CPU hog, that I'm less sure of. You'd have to look at the interactive scoring stuff in ULE to debug that. How are you setting your program to a "normal" priority that is still higher than openssl? Are you using nice? Hmm, during your hiccup it looks like openssl got two time slices back to back rather than a single slice. Also, note that in the hiccup graph, both threads have the same priority (183), so openssl effectively has the same priority as timecheck. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Feb 24, 2011, at 7:00 AM, Nathan Whitehorn wrote: > Thanks! I've received basically this patch from a couple people now. I'm > going to investigate whether this is a more generic way to get this > information (so the list doesn't grow infinitely long), and will commit this > if I can't. Having CAM devices be part of newbus would simplify this a very > great deal... See: http://people.freebsd.org/~marcel/gpt.diff It was my initial attempt of creating a generic (ncurses-based) partition editor that uses gpart. (the name of the patch relates to the perforce branch it was done on, not the partitioning scheme). In it you'll find a diff for sbin/pe/disk.c that contains logic for presenting a friendly "disk" name. Not complete, but maybe good for inspiration... FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Process timing issue
on 24/02/2011 16:18 Jerome Flesch said the following: > Thanks for your explanations. It helped greatly. Using ktrdump and > schedgraph.py > and after modifying our test program to set and unset automatically > debug.ktr.mask, I've been able to get useful information. > > First, It made me realize that task switching, with default settings and 2 > active > processes, only occurs each 100ms. Knowing that, expecting a latency time > around > 100ms was kind of silly :) > > Next, it seems most of the latency pikes are due to a process starting or > waking > up. For instance, it usually happens when the openssl speed test is started ( > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_start.png > ) or when pagedaemon wakes up (I forgot to disable the swap and my test > program > used too much memory to store the result values ...). I'm not sure why, but > when > we start openssl, it is often allowed to run for >= 300ms, even with our test > program set to real time priority. My intuition is that, at first, it's > considered > as an interactive process, until the scheduler realizes it's not. But then, > does > anyone know why it would take more than 300ms for the scheduler to realize > that ? > > Anyway, by setting kern.sched.interact=5 (so openssl isn't considered as an > interactive process), kern.sched.slice=3 (to get an high enough scheduling > resolution), and our program to real-time priority, we got rid of both > problems. > I'm just a little bit worried about kern.sched.slice=3. Is there any known > side > effect when reducing slices size ? > > Also, another issue remain: We were hoping to keep our program with a normal > priority. However when we set our test program to a normal priority (but > still an > higher priority than openssl), both get 50% of the CPU (I guess this is to be > expected), and from time to time we have a "hiccup" in the scheduling: > http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.png . > Is > there any way to avoid them ? In other words, is it possible to make sure > that the > low priority process never gets more CPU time than the high priority one ? The problems that you describe here sound very much like the issues that John Baldwin has been trying to solve a short while ago. My recollection is that he committed some improvements for real time priority processes. Perhaps he'll have some additional insights based on his observations and testing. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
On Thu, 24 Feb 2011 09:00:44 -0600 Nathan Whitehorn wrote: > Having CAM devices be part of newbus would > simplify this a very great deal... It's required if we're ever going to have suspend/resume working properly because currently CAM doesn't get a suspend notification, so doesn't know to spin-down disks etc. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cosmetic path to bsdinstall
Thanks! I've received basically this patch from a couple people now. I'm
going to investigate whether this is a more generic way to get this
information (so the list doesn't grow infinitely long), and will commit
this if I can't. Having CAM devices be part of newbus would simplify
this a very great deal...
-Nathan
On 02/23/11 06:37, Mitya wrote:
Add usually used RAID controller
--- usr.sbin/bsdinstall/partedit/part_wizard.c.orig2011-02-19
17:22:06.0 +0200
+++ usr.sbin/bsdinstall/partedit/part_wizard.c2011-02-21
17:20:28.0 +0200
@@ -122,6 +122,18 @@
strcat(diskdesc, " ATA Hard Disk");
else if (strncmp(pp->lg_name, "da", 2) == 0)
strcat(diskdesc, " SCSI Hard Disk");
+else if (strncmp(pp->lg_name, "aacd", 4) == 0)
+strcat(diskdesc, " Adaptec Raid Disk");
+else if (strncmp(pp->lg_name, "amrd", 4) == 0)
+strcat(diskdesc, " LSI Raid Disk");
+else if (strncmp(pp->lg_name, "mfid", 4) == 0)
+strcat(diskdesc, " LSI Raid Disk");
+else if (strncmp(pp->lg_name, "mlxd", 4) == 0)
+strcat(diskdesc, " Mylex Raid Disk");
+else if (strncmp(pp->lg_name, "twed", 4) == 0)
+strcat(diskdesc, " 3ware Raid Disk");
+else if (strncmp(pp->lg_name, "pst", 3) == 0)
+strcat(diskdesc, " Promise Raid Disk");
else if (strncmp(pp->lg_name, "md", 2) == 0)
strcat(diskdesc, " Memory Disk");
else if (strncmp(pp->lg_name, "cd", 2) == 0) {
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Process timing issue
Thanks for your explanations. It helped greatly. Using ktrdump and schedgraph.py and after modifying our test program to set and unset automatically debug.ktr.mask, I've been able to get useful information. First, It made me realize that task switching, with default settings and 2 active processes, only occurs each 100ms. Knowing that, expecting a latency time around 100ms was kind of silly :) Next, it seems most of the latency pikes are due to a process starting or waking up. For instance, it usually happens when the openssl speed test is started ( http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_openssl_start.png ) or when pagedaemon wakes up (I forgot to disable the swap and my test program used too much memory to store the result values ...). I'm not sure why, but when we start openssl, it is often allowed to run for >= 300ms, even with our test program set to real time priority. My intuition is that, at first, it's considered as an interactive process, until the scheduler realizes it's not. But then, does anyone know why it would take more than 300ms for the scheduler to realize that ? Anyway, by setting kern.sched.interact=5 (so openssl isn't considered as an interactive process), kern.sched.slice=3 (to get an high enough scheduling resolution), and our program to real-time priority, we got rid of both problems. I'm just a little bit worried about kern.sched.slice=3. Is there any known side effect when reducing slices size ? Also, another issue remain: We were hoping to keep our program with a normal priority. However when we set our test program to a normal priority (but still an higher priority than openssl), both get 50% of the CPU (I guess this is to be expected), and from time to time we have a "hiccup" in the scheduling: http://jflesch.kwain.net/~jflesch/sys_latence/sched/sched_graph_hicups.png . Is there any way to avoid them ? In other words, is it possible to make sure that the low priority process never gets more CPU time than the high priority one ? On 23.02.2011 02:08, Ryan Stone wrote: To debug weird scheduling issues I find it helpful to start by looking at a schedgraph. schedgraph is a tool that can display a graphical representation of what the scheduler was doing over a small slice of time. The one downside is that you have to recompile your kernel to get the hooks that collect the necessary data, but it sounds like your problem is pretty easy to reproduce and so that shouldn't be a big problem. To enable the hooks, put the following in your kernel conf: options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED options KTR_ENTIRES=(128*1024) Then rebuild and install the new kernel. Next, run your test. The instant that your test has detected the long delay, set the sysctl debug.ktr.mask to 0. The scheduler hooks record data into a ring buffer, so the interesting data can be flushed out within seconds. Clearing that sysctl will stop any further events from being logged, which means that the interesting data will stay there until you go and collect it. You can get the raw data by redirecting the output of "ktrdump -ct" into a file. Then from any machine with a graphical interface(FreeBSD with X installed, Windows, Mac, whatever) and python installed, run: $ python schedgraph.py /path/to/ktrdump/output You can get schedgraph.py from /usr/src/tools/sched. If you want to collect the data again, set the sysctl debug.ktr.mask back to 0x2000 to restart gathering scheduler data. Ryan
