Re: TTY task group scheduling
On Fri, Nov 19, 2010 at 5:27 PM, Oliver Pinter wrote: > My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP > system), > I tested 8-STABLE, but that is not too responsive, the solution is: > 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 > After this setting, the system is likely responsive as 7-STABLE. > > On 11/19/10, Garrett Cooper wrote: >> On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter >> wrote: >>> http://lkml.org/lkml/2010/11/16/392 >>> >>> On 11/18/10, O. Hartmann wrote: On 11/18/10 02:30, grarpamp wrote: > Just documenting regarding interactive performance things. > This one's from Linux. > > http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 Well, it would be nice to have those improvements in FreeBSD, but I doubt this will make it in due time to FreeBSD's kernel. >> >> And my one line fix: >> >> renice 10 `pidof firefox-bin` >> >> Instantly my system is snappier (and in fact my system got really >> laggy after applying the preempt sysctl that everyone recommended >> before)... Performance issue with firefox maybe :P? I don't see the >> point of adding an additional layer to complicate the system (and >> essentially slow it down) if all you're trying to do is better >> describe the nice'ing problem, unless this logic is what you want to >> do strictly for desktop users in PCBSD, etc who may not have the >> technical wherewithal to accomplish this task. >> >> Besides, the Linux kernel has different compile time profiles for >> different workloads, so maybe it just works better for them because >> they already have a means for describing that functionality, whereas >> FreeBSD is more generic. >> >> It would be nice to describe this in a document though so people could >> also decide how to tune the system for themselves and not deal with a >> patch like what's noted above by the penguin crowd because it will >> invariably fail under some workloads or conditions (I have yet to see >> a one-size-fits-all solution in this area). >> >> >> SCHED_ULE improvements though should be looked into if possible, >> because there are some potential items that could be done to cluster >> processes together better, maybe. >> Ugh. Looks like this was the only machine that I setup recently where I didn't set kern.hz... Ok, will retry after building and installing a whole new world *queue lame Disney music here* and kernel. Thanks for the obvious reminder... -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: TTY task group scheduling
My desktop running 7-STABLE with 100Hz and NOPREEMPT (it's a 4core SMP system), I tested 8-STABLE, but that is not too responsive, the solution is: 100Hz NOPREEMPT + kern.sched.preempt_thresh=224 After this setting, the system is likely responsive as 7-STABLE. On 11/19/10, Garrett Cooper wrote: > On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter > wrote: >> http://lkml.org/lkml/2010/11/16/392 >> >> On 11/18/10, O. Hartmann wrote: >>> On 11/18/10 02:30, grarpamp wrote: Just documenting regarding interactive performance things. This one's from Linux. http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >>> >>> Well, >>> it would be nice to have those improvements in FreeBSD, but I doubt this >>> will make it in due time to FreeBSD's kernel. > > And my one line fix: > > renice 10 `pidof firefox-bin` > > Instantly my system is snappier (and in fact my system got really > laggy after applying the preempt sysctl that everyone recommended > before)... Performance issue with firefox maybe :P? I don't see the > point of adding an additional layer to complicate the system (and > essentially slow it down) if all you're trying to do is better > describe the nice'ing problem, unless this logic is what you want to > do strictly for desktop users in PCBSD, etc who may not have the > technical wherewithal to accomplish this task. > > Besides, the Linux kernel has different compile time profiles for > different workloads, so maybe it just works better for them because > they already have a means for describing that functionality, whereas > FreeBSD is more generic. > > It would be nice to describe this in a document though so people could > also decide how to tune the system for themselves and not deal with a > patch like what's noted above by the penguin crowd because it will > invariably fail under some workloads or conditions (I have yet to see > a one-size-fits-all solution in this area). > > > SCHED_ULE improvements though should be looked into if possible, > because there are some potential items that could be done to cluster > processes together better, maybe. > > > 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: TTY task group scheduling
On 11/19/10 16:49, Taku YAMAMOTO wrote: I have a dumb local hack to grant ts_slice proportional to the duration the waking thread slept rather than unconditionally reset to sched_slice. --- sys/kern/sched_ule.c.orig +++ sys/kern/sched_ule.c @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) u_int hzticks; hzticks = (ticks - slptick)<< SCHED_TICK_SHIFT; + if (hzticks> SCHED_SLP_RUN_MAX) + hzticks = SCHED_SLP_RUN_MAX; ts->ts_slptime += hzticks; + /* Grant additional slices after we sleep. */ + ts->ts_slice += hzticks / tickincr; + if (ts->ts_slice > sched_slice) + ts->ts_slice = sched_slice; If I read it correctly, now instead of the slice given to the thread being always sched_slice, now it is reduced to a value smaller than sched_slice based on how long did the thread sleep? How does that help? sched_interact_update(td); sched_pctcpu_update(ts); } - /* Reset the slice value after we sleep. */ - ts->ts_slice = sched_slice; sched_add(td, SRQ_BORING); } ___ 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: A big-ish machine, cannot boot
On 11/19/10 19:15, Andriy Gapon wrote: on 19/11/2010 20:02 Sean Bruno said the following: What I've seen is that the long pause occurs between the display of the SMAP (boot verbose) and the copywrite notice. The delay gets worse with larger memory maps. How much memory do we talk about? 24 GB. I think I saw reports of larger memories so I don't think this is critical (unless something's wrong). I wonder if it could be the code that touches each page to test its usability. Some printf-profiling could be enlightening. No printf debugging this time, I don't have physical access to it for the weekend (but have ssh). Here's the CPU topology (correctly parsed, thankfully :) ), if someone's interested: biggie# sysctl kern.sched.topology_spec kern.sched.topology_spec: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 0, 1 THREAD groupname="SMT">SMT group 2, 3 THREAD groupname="SMT">SMT group 4, 5 THREAD groupname="SMT">SMT group 6, 7 THREAD groupname="SMT">SMT group 8, 9 THREAD groupname="SMT">SMT group 10, 11 THREAD groupname="SMT">SMT group 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23 12, 13 THREAD groupname="SMT">SMT group 14, 15 THREAD groupname="SMT">SMT group 16, 17 THREAD groupname="SMT">SMT group 18, 19 THREAD groupname="SMT">SMT group 20, 21 THREAD groupname="SMT">SMT group 22, 23 THREAD groupname="SMT">SMT group ___ 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: A big-ish machine, cannot boot
On 19 November 2010 18:17, James R. Van Artsdalen wrote: > Ivan Voras wrote: >> Unfortunately, the kernel hangs on boot. The loader finishes, the twirly >> starts spinning but then hangs. Enabling verbose booting results in >> nothing new - no kernel messages at all. > > I don't think "loader finishes" is correct. Can you break to the loader > command line at the beastie menu? Yes. Everything in the loader itself works fine, including hardware detection. > At the time of the twirlie I think that the loader is copying the kernel > to memory. Perhaps it is having trouble with disk reads, or has a bad > memory map. > > How many disks are attached, and what filesystem type does /boot live > on? And what does Fixit mode see (from whatever installed that system)? There are three RAID volumes visible to the system, and all three are successfully detected and used. root and /boot are completely standard UFS. It is "legacy free" hardware in the sense that it doesn't have PS2 ports, and has the latest generation CPUs with a whole bunch of new technologies. ___ 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: TTY task group scheduling
In the last episode (Nov 19), Alexander Leidinger said: > Quoting Alexander Best (from Fri, 19 Nov 2010 00:17:10 > +): > > 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* or > > thereabouts > > 17:51 @ Genesys : you could kldload new ones and switch to them on the fly > > 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it > > into src tree. by now it's probably outdated and needs to be reworked quite > > a bit. > > > > > > does anybody know something about this? > > I'm aware of the I/O scheduling code (which is now available at least > in -current), but I do not remember CPU scheduling code from Luigi. > Are you sure Genesys didn't mix up something by accident? I am rarely mixed up :) A quick search didn't bring up a direct reference, but here's a mention of it from Luigi: http://lists.freebsd.org/pipermail/freebsd-hackers/2004-November/008891.html -- Dan Nelson dnel...@allantgroup.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: TTY task group scheduling
On Fri, Nov 19, 2010 at 1:10 PM, Oliver Pinter wrote: > http://lkml.org/lkml/2010/11/16/392 > > On 11/18/10, O. Hartmann wrote: >> On 11/18/10 02:30, grarpamp wrote: >>> Just documenting regarding interactive performance things. >>> This one's from Linux. >>> >>> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 >> >> Well, >> it would be nice to have those improvements in FreeBSD, but I doubt this >> will make it in due time to FreeBSD's kernel. And my one line fix: renice 10 `pidof firefox-bin` Instantly my system is snappier (and in fact my system got really laggy after applying the preempt sysctl that everyone recommended before)... Performance issue with firefox maybe :P? I don't see the point of adding an additional layer to complicate the system (and essentially slow it down) if all you're trying to do is better describe the nice'ing problem, unless this logic is what you want to do strictly for desktop users in PCBSD, etc who may not have the technical wherewithal to accomplish this task. Besides, the Linux kernel has different compile time profiles for different workloads, so maybe it just works better for them because they already have a means for describing that functionality, whereas FreeBSD is more generic. It would be nice to describe this in a document though so people could also decide how to tune the system for themselves and not deal with a patch like what's noted above by the penguin crowd because it will invariably fail under some workloads or conditions (I have yet to see a one-size-fits-all solution in this area). SCHED_ULE improvements though should be looked into if possible, because there are some potential items that could be done to cluster processes together better, maybe. 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: TTY task group scheduling
http://lkml.org/lkml/2010/11/16/392 On 11/18/10, O. Hartmann wrote: > On 11/18/10 02:30, grarpamp wrote: >> Just documenting regarding interactive performance things. >> This one's from Linux. >> >> http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1 > > Well, > it would be nice to have those improvements in FreeBSD, but I doubt this > will make it in due time to FreeBSD's kernel. > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-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: www/chromium crashing whole system
can you try disable the chrome sandbox feature? chmod -s chrome-sandbox mv chrome-sandbox chrome-sandbox.disabled_feature and after this, the problem is still represented? under linux with grsec path, with enabled sandbox, do not started, I know, that is a fully different problem On 11/19/10, Alexander Best wrote: > On Tue Nov 16 10, Robert N. M. Watson wrote: >> >> On 15 Nov 2010, at 22:19, Alexander Best wrote: >> >> > thanks for all your help. i've recently switched to chromium 6.0.472.63 >> > and so far my computer has been very stable. >> > >> > if i experience more lock ups i'll let you know and try to figure out a >> > way to >> > gain access to some more debugging data. >> >> I'd prefer we try to figure out why your system was crashing now -- the >> kernel bug has not gone away just because Chromium is no longer triggering >> it. Working around the bug means someone else gets to run into it later -- >> perhaps when it's 9.0-RELEASE rather than 9-CURRENT... > > "GOOD" news btw: the new chromium port just crashed my system. ;) so the > issue is still there. > > and be issue i mean the code that triggers the crash. > >> >> Robert > -- > a13x > ___ > 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: A big-ish machine, cannot boot
On Nov 19, 2010, at 12:42 PM, Antony Mawer wrote: > If you select any text in the message then click reply, it only quotes > the selected text (not entirely intuitive, but that's the way they > decided to make it work). Ah, yes: https://bugzilla.mozilla.org/show_bug.cgi?id=23394 There's a standard for mail and news readers (GNKSA) which expects "Provides adequate quotation and attribution facilities"; it's expected that there should be a preference which allows a user to decide whether to quote all text or just the selected text when composing a reply. Regards, -- -Chuck ___ 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: A big-ish machine, cannot boot
On Sat, Nov 20, 2010 at 2:51 AM, Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: >> Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame it] If you select any text in the message then click reply, it only quotes the selected text (not entirely intuitive, but that's the way they decided to make it work). --Antony ___ 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: aperf/mperf
On 11/19/2010 6:39 AM, Andriy Gapon wrote: > > I am thinking about providing two APIs for this. > > 1. KPI > void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); > > 2. Userland > sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. > > But I am not sure where to put the code for both APIs. > Adding another device under cpu seems like an overkill. These can be exported as a common interface from cpufreq (dev,cpu.X.perf_stats) and supplied by the child acpi_perf driver on each cpu. -- Nate ___ 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: [Call for Tests] PAT issue on Apple hardware
On Tuesday 16 November 2010 03:30 pm, Jung-uk Kim wrote: > On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: > > Often times I hear complaints like "my Mac hangs after upgrading > > to 8.1" or "snapshot CD hangs on my brand new Mac". I know some > > of these complaints started happening when we switched to new PAT > > layout. It is so puzzling because it never happened on non-Apple > > hardware, AFAIK. I really like to fix this problem but I cannot > > afford a Mac. :-P > > > > If you are one of those lucky people, please test the attached > > patch and report your hardware model and any improvement or > > regression. > > > > Also, I added a new tunable "vm.pmap.pat_works" so that you can > > turn it off from loader (i.e., "set vm.pmap.pat_works=0") and > > restore old behaviour without recompiling a new kernel. > > I revised this patch to make it more robust. > > http://people.freebsd.org/~jkim/pat-current.diff > > Also, I prepared a patch for stable/8. If you have recent Apple > hardware and it hangs with 8.1 or stable/8, please test this patch. > > http://people.freebsd.org/~jkim/pat-stable.diff Anyone? I don't want to commit it blindly. :-( 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: A big-ish machine, cannot boot
On Fri, 2010-11-19 at 09:08 -0800, Ivan Voras wrote: > On 19 November 2010 18:04, Garrett Cooper wrote: > > A similar issue occurred with an HP box recently (in the last 3-4 > > months?). I'd check the archives for more details. > > Yes, I remembered the post by Sean Bruno but then I also remembered > people replying they have successfully booted larger machines than his > or mine. > > What is the last thing the loader does before booting the kernel? > Enumberating memory regions? > ___ > 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" What I've seen is that the long pause occurs between the display of the SMAP (boot verbose) and the copywrite notice. The delay gets worse with larger memory maps. Sean ___ 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: A big-ish machine, cannot boot
On Friday 19 November 2010 12:04 pm, Garrett Cooper wrote: > On Fri, Nov 19, 2010 at 8:59 AM, Andriy Gapon wrote: > > on 19/11/2010 18:57 Ivan Voras said the following: > >> On 19 November 2010 17:13, Gary Jennejohn wrote: > >>> On Fri, 19 Nov 2010 17:51:22 +0200 > >>> > >>> Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: > > Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame > it] > > Perhaps I am wrong, but isn't the "twirly" shown by the > loader, still? Not sure if the kernel does that. > >>> > >>> Yup, that's the boot loader. �The kernel spits out printfs. > >> > >> Good news, of sorts - I left while I went for dinner and > >> apparently it did boot in the meantime. So it's not a complete > >> hang, it just takes unexpectedly long (10+ minutes?) > >> > >> I'm currently running "make -j24 buildworld" and once it boots > >> it looks very fast! > > > > You ought to determine a cause of the long boot, though. > > No compromises or excuses! :-) > > A similar issue occurred with an HP box recently (in the last 3-4 > months?). I'd check the archives for more details. I bet these are "legacy free" machines, right? I recently noticed that recent Intel chipsets cause incredibly long delays when non-existent ISA ports are accessed, most notably AT keyboard ports. (My gut tells me it is going in and out of SMM repeatedly for nothing.) Back in the old days, when we had real ISA bus, it used to delay very short and fixed amount time. Those days, this behaviour was even (ab)used as a delay function where a real timer is not available yet. ;-) Try getting rid of all unnecessary device drivers from your kernel configuration. 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: A big-ish machine, cannot boot
on 19/11/2010 20:02 Sean Bruno said the following: > What I've seen is that the long pause occurs between the display of the > SMAP (boot verbose) and the copywrite notice. The delay gets worse with > larger memory maps. How much memory do we talk about? I wonder if it could be the code that touches each page to test its usability. Some printf-profiling could be enlightening. -- 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: taskqueue_create() name parameter lieftime
On Friday, November 19, 2010 11:20:04 am Andriy Gapon wrote: > on 16/11/2010 15:27 John Baldwin said the following: > > On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: > >> > >> taskqueue_create() documentation never explicitly says this, but current > >> taskqueue_create() implementation just stores a 'name' pointer parameter > >> internally. Thus it depends on the 'name' having a life time encompassing > >> that of > >> the taskqueue. > >> I think that alternatively we could have copied the name (or a portion of > >> it) into > >> an internal buffer. > >> I don't any argument for either approach, just curious which one looks more > >> preferable from general (FreeBSD, kernel) programming practices point of > >> view. > > > > Hmm, in many other places we store a separate copy (e.g. all the interrupt > > code uses separate MAXCOMLEN char arrays to hold names). If that is easy to > > do, that is probably the best approach. > > BTW, tq_name doesn't seem to be used anywhere at all. > Perhaps just drop it? But still could be useful in a debugger, though. If it's not used anywhere I would just drop it. -- 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: A big-ish machine, cannot boot
Ivan Voras wrote: > Unfortunately, the kernel hangs on boot. The loader finishes, the twirly > starts spinning but then hangs. Enabling verbose booting results in > nothing new - no kernel messages at all. I don't think "loader finishes" is correct. Can you break to the loader command line at the beastie menu? At the time of the twirlie I think that the loader is copying the kernel to memory. Perhaps it is having trouble with disk reads, or has a bad memory map. How many disks are attached, and what filesystem type does /boot live on? And what does Fixit mode see (from whatever installed that system)? ___ 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: [RFC] ifconfig description support in rc.d
On Fri, Nov 19, 2010 at 2:55 AM, Sergey Kandaurov wrote: > On 11 October 2010 14:29, Hiroki Sato wrote: >> Hi, >> >> pluknet wrote >> in : >> >> pl> On 27 August 2010 00:09, Doug Barton wrote: >> pl> > On 08/26/2010 12:53 PM, pluknet wrote: >> pl> >> >> pl> >> [cc'ing current@ as rc@ looks too quite] >> pl> >> >> pl> >> Hi. >> pl> >> >> pl> >> Since ifconfig has grown to label interfaces with >> pl> >> ifconfig $ifname description "foobar", what about >> pl> >> to give it more life and store i/face descriptions >> pl> >> semi-permanently, so they will survive between reboots? >> pl> >> >> pl> >> This patch adds a functionality to rc.d to label >> pl> >> interfaces at boot time. >> pl> >> >> pl> >> Comments are welcome. >> pl> > >> pl> > This seems like a good addition, thanks. Please also write a patch for >> pl> > rc.conf.5 to describe this new functionality and I'll be happy to >> commit it. >> pl> >> pl> Xin Li helped me with updating rc.conf.5 (thanks!). >> pl> It's included in attached patch. >> (snip) >> pl> >> + # ifconfig_IF_descr >> pl> >> + for _if in `ifconfig -l`; do >> >> I think using "ifconfig -l" here is not a good idea. Setting a >> description for each interface in a function invoked by ifn_start() >> would be better. >> >> This is beacuse the netif script can be run not only at boottime but >> also via devd or by hand for a specific interface. So, if the >> ifnet_descr is there, "/etc/rc.d/netif start IF" does not make it >> run. Since the description is a per-interface property, >> "/etc/rc.d/netif start IF" should set one, and "/etc/rc.d/netif stop >> IF" should clear one, IMHO. >> >> Also, "ifconfig -l" is not compatible with $network_interfaces, so >> you need to use list_net_interface() for that purpose instead (if you >> move ifnet_descr() into ifn_start() it is useless, though). >> > > Actually, both versions were developed at the same time. > This one follows "netif" approach. Somehow it was rejected > by me for some reasons which I don't remember for now. > That's why I didn't include it to my original message. > > Please, see attached. + _ifdescr="`get_if_var $_if ifconfig_IF_descr`" + if [ ! -z "$_ifdescr" ]; then + ifconfig $_if descr "$_ifdescr" + fi + + return 0 What if the above fails? There are other potential problem areas as well in network.subr (ifscript_up for instance). Thanks, -Garrett > P.S. > Google marks patches as (application/octet-stream). Bad Google. Only if the extension isn't .patch (and it's not just Google -- blame it on other software like Mailman as well) :)... ___ 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: old references to vfs_mountroot_try()
On Nov 19, 2010, at 2:09 AM, Sergey Kandaurov wrote: > On 19 November 2010 02:14, Alexander Best wrote: >> hi there, >> >> vfs_mountroot_try() seems to have been removed, yet the src still contains >> three references to it: >> >> vfs_mount.c:386 >> vfs_mount.c:723 >> freebsd32_misc.c:2368 >> > > So, what about just to rename those comments to reflect function name change? > > Index: sys/kern/vfs_mount.c > === > --- sys/kern/vfs_mount.c(revision 215516) > +++ sys/kern/vfs_mount.c(working copy) > @@ -383,7 +383,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of nmount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > +* MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ >uap->flags &= ~MNT_ROOTFS; > Keep it vague. Just change the line to "MNT_ROOTFS should only be set by the kernel when mounting its root file system". The parse_mount() function name has no meaning other than within sys/kern/vfs_mountroot.c, so referring to it isn't making things clear. 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: A big-ish machine, cannot boot
On 19 November 2010 18:04, Garrett Cooper wrote: > A similar issue occurred with an HP box recently (in the last 3-4 > months?). I'd check the archives for more details. Yes, I remembered the post by Sean Bruno but then I also remembered people replying they have successfully booted larger machines than his or mine. What is the last thing the loader does before booting the kernel? Enumberating memory regions? ___ 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: A big-ish machine, cannot boot
On 19 November 2010 17:59, Andriy Gapon wrote: > on 19/11/2010 18:57 Ivan Voras said the following: >> On 19 November 2010 17:13, Gary Jennejohn wrote: >>> On Fri, 19 Nov 2010 17:51:22 +0200 >>> Andriy Gapon wrote: >>> on 19/11/2010 17:41 Ivan Voras said the following: > Fujitsu TX300 [Thunderbird 3 sometimes fails quoting while replying - blame it] Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? Not sure if the kernel does that. >>> >>> Yup, that's the boot loader. The kernel spits out printfs. >> >> Good news, of sorts - I left while I went for dinner and apparently it >> did boot in the meantime. So it's not a complete hang, it just takes >> unexpectedly long (10+ minutes?) >> >> I'm currently running "make -j24 buildworld" and once it boots it >> looks very fast! > > You ought to determine a cause of the long boot, though. > No compromises or excuses! :-) Yes, it does bug me. It looked like a kernel hang (not loader) since the machine didn't respond to ctrl-alt-del, only on cold boot. No BIOS options seemed to help - not disabling SMP nor trying different memory options or timings. ___ 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: A big-ish machine, cannot boot
On Fri, Nov 19, 2010 at 8:59 AM, Andriy Gapon wrote: > on 19/11/2010 18:57 Ivan Voras said the following: >> On 19 November 2010 17:13, Gary Jennejohn wrote: >>> On Fri, 19 Nov 2010 17:51:22 +0200 >>> Andriy Gapon wrote: >>> on 19/11/2010 17:41 Ivan Voras said the following: > Fujitsu TX300 [Thunderbird 3 sometimes fails quoting while replying - blame it] Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? Not sure if the kernel does that. >>> >>> Yup, that's the boot loader. The kernel spits out printfs. >> >> Good news, of sorts - I left while I went for dinner and apparently it >> did boot in the meantime. So it's not a complete hang, it just takes >> unexpectedly long (10+ minutes?) >> >> I'm currently running "make -j24 buildworld" and once it boots it >> looks very fast! > > You ought to determine a cause of the long boot, though. > No compromises or excuses! :-) A similar issue occurred with an HP box recently (in the last 3-4 months?). I'd check the archives for more details. -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: A big-ish machine, cannot boot
on 19/11/2010 18:57 Ivan Voras said the following: > On 19 November 2010 17:13, Gary Jennejohn wrote: >> On Fri, 19 Nov 2010 17:51:22 +0200 >> Andriy Gapon wrote: >> >>> on 19/11/2010 17:41 Ivan Voras said the following: Fujitsu TX300 >>> >>> [Thunderbird 3 sometimes fails quoting while replying - blame it] >>> >>> Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? >>> Not sure if the kernel does that. >>> >> >> Yup, that's the boot loader. The kernel spits out printfs. > > Good news, of sorts - I left while I went for dinner and apparently it > did boot in the meantime. So it's not a complete hang, it just takes > unexpectedly long (10+ minutes?) > > I'm currently running "make -j24 buildworld" and once it boots it > looks very fast! You ought to determine a cause of the long boot, though. No compromises or excuses! :-) -- 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: A big-ish machine, cannot boot
On 19 November 2010 17:13, Gary Jennejohn wrote: > On Fri, 19 Nov 2010 17:51:22 +0200 > Andriy Gapon wrote: > >> on 19/11/2010 17:41 Ivan Voras said the following: >> > Fujitsu TX300 >> >> [Thunderbird 3 sometimes fails quoting while replying - blame it] >> >> Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? >> Not sure if the kernel does that. >> > > Yup, that's the boot loader. The kernel spits out printfs. Good news, of sorts - I left while I went for dinner and apparently it did boot in the meantime. So it's not a complete hang, it just takes unexpectedly long (10+ minutes?) I'm currently running "make -j24 buildworld" and once it boots it looks very fast! ___ 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: A big-ish machine, cannot boot
On 19 November 2010 16:51, Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: >> Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame it] > > Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? > Not sure if the kernel does that. Could be, I'll try more fiddling with BIOS. ___ 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: new cpuid bits
On Fri, 19 Nov 2010 17:39:53 +0200 Andriy Gapon wrote: > > Guys, > > I would like to add definitions for couple more useful CPUID bits, but I am > greatly confused about how to name them. > I failed to deduce the naming convention from the existing definitions and I > am > not sure how to make the names proper and descriptive. > > The bits in question are returned by CPUID.6 in EAX and ECX. > CPUID.6 block is described by both AMD and Intel as "Thermal and Power > Management > (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is > defined for both. > > Description/naming of the bits from the specifications: > EAX[0]: Digital temperature sensor is supported if set > EAX[1]: Intel Turbo Boost Technology Available > EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. > ECX[0]: > Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and > ACNT > MSRs). > AMD: EffFreq: effective frequency interface. > > How does the following look to you? > I will appreciate suggestions/comments. > Thanks! > > Index: sys/amd64/include/specialreg.h > === > --- sys/amd64/include/specialreg.h(revision 215524) > +++ sys/amd64/include/specialreg.h(working copy) > @@ -136,6 +136,15 @@ > #define CPUID2_AESNI0x0200 > > /* > + * Important bits in the Thermal and Power Management flags > + * CPUID.6 EAX and ECX. > + */ > +#define CPUTPM1_SENSOR 0x0001 > +#define CPUTPM1_TURBO 0x0002 > +#define CPUTPM1_ARAT0x0004 > +#define CPUTPM2_EFFREQ 0x0001 > + > +/* > * Important bits in the AMD extended cpuid flags > */ > #define AMDID_SYSCALL 0x0800 > Maybe add a comment in which register the bits are to be found, like in the text? -- Gary Jennejohn ___ 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: taskqueue_create() name parameter lieftime
on 16/11/2010 15:27 John Baldwin said the following:
> On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote:
>>
>> taskqueue_create() documentation never explicitly says this, but current
>> taskqueue_create() implementation just stores a 'name' pointer parameter
>> internally. Thus it depends on the 'name' having a life time encompassing
>> that of
>> the taskqueue.
>> I think that alternatively we could have copied the name (or a portion of
>> it) into
>> an internal buffer.
>> I don't any argument for either approach, just curious which one looks more
>> preferable from general (FreeBSD, kernel) programming practices point of
>> view.
>
> Hmm, in many other places we store a separate copy (e.g. all the interrupt
> code uses separate MAXCOMLEN char arrays to hold names). If that is easy to
> do, that is probably the best approach.
BTW, tq_name doesn't seem to be used anywhere at all.
Perhaps just drop it? But still could be useful in a debugger, though.
Anyway, here is a possible change:
diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c
index 49ddce2..9b8ae66 100644
--- a/sys/kern/subr_taskqueue.c
+++ b/sys/kern/subr_taskqueue.c
@@ -53,7 +53,6 @@ struct taskqueue_busy {
struct taskqueue {
STAILQ_HEAD(, task) tq_queue;
- const char *tq_name;
taskqueue_enqueue_fntq_enqueue;
void*tq_context;
TAILQ_HEAD(, taskqueue_busy) tq_active;
@@ -62,6 +61,7 @@ struct taskqueue {
int tq_tcount;
int tq_spin;
int tq_flags;
+ chartq_name[MAXCOMLEN];
};
#defineTQ_FLAGS_ACTIVE (1 << 0)
@@ -106,7 +106,7 @@ _taskqueue_create(const char *name, int mflags,
STAILQ_INIT(&queue->tq_queue);
TAILQ_INIT(&queue->tq_active);
- queue->tq_name = name;
+ strlcpy(queue->tq_name, name, sizeof(queue->tq_name));
queue->tq_enqueue = enqueue;
queue->tq_context = context;
queue->tq_spin = (mtxflags & MTX_SPIN) != 0;
--
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: A big-ish machine, cannot boot
On Fri, 19 Nov 2010 17:51:22 +0200 Andriy Gapon wrote: > on 19/11/2010 17:41 Ivan Voras said the following: > > Fujitsu TX300 > > [Thunderbird 3 sometimes fails quoting while replying - blame it] > > Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? > Not sure if the kernel does that. > Yup, that's the boot loader. The kernel spits out printfs. -- Gary Jennejohn ___ 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: A big-ish machine, cannot boot
on 19/11/2010 17:41 Ivan Voras said the following: > Fujitsu TX300 [Thunderbird 3 sometimes fails quoting while replying - blame it] Perhaps I am wrong, but isn't the "twirly" shown by the loader, still? Not sure if the kernel does that. -- 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: TTY task group scheduling
On Thu, 18 Nov 2010 21:30:16 +0100 "O. Hartmann" wrote: > On 11/18/10 19:55, Lucius Windschuh wrote: > > 2010/11/18 Andriy Gapon: > >> [Grouping of processes into TTY groups] > >> > >> Well, I think that those improvements apply only to a very specific usage > >> pattern > >> and are greatly over-hyped. > > > > But there are serious issue if you use FreeBSD as a desktop OS with > > SMP and SCHED_ULE, or? > > Because currently, my machine is barely usable if a compile job with > > parallelism is running. Movies stutter, Firefox hangs. And even nice > > -n 20 doesn't do the job in every case, as +20 seems not to be the > > idle priority anymore?!? > > And using "idprio 1 $cmd" as a workaround is, well, a kludge. > > I am not sure if TTY grouping is the right solution, if you look at > > potentially CPU-intensive GUI applications that all run on the same > > TTY (or no TTY at all? Same problem). > > Maybe, we could simply enhance the algorithm that decides if a task is > > interactive? That would also improve the described situation. > > > > Regards, > > > > Lucius > > Stuttering Response, being stuck for over 20 seconds also happens when I > start updating the OS' sources via svn. This happens on all boxes, some > of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O, > doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those > phenomena are most seen when you interact with the machine via X11 > clients. I think it's hard to realize if a server only does console I/O, > but console also seems to be stuck sometimes. It would be worth checking > this with some 'benchmark'. X11 in its kind of oldish incarnation on > FreeBSD seems to contribute most to those slowdowns, what so ever. I guess schedulers can hardly distinguish heavy disk I/Os from nanosleep()s and user-interactions; schedulers think both as voluntary sleep. To make the matters worse, the current implementation of SCHED_ULE reassigns ts_slice on sched_wakeup() no matter how short the sleep was. I have a dumb local hack to grant ts_slice proportional to the duration the waking thread slept rather than unconditionally reset to sched_slice. --- sys/kern/sched_ule.c.orig +++ sys/kern/sched_ule.c @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) u_int hzticks; hzticks = (ticks - slptick) << SCHED_TICK_SHIFT; + if (hzticks > SCHED_SLP_RUN_MAX) + hzticks = SCHED_SLP_RUN_MAX; ts->ts_slptime += hzticks; + /* Grant additional slices after we sleep. */ + ts->ts_slice += hzticks / tickincr; + if (ts->ts_slice > sched_slice) + ts->ts_slice = sched_slice; sched_interact_update(td); sched_pctcpu_update(ts); } - /* Reset the slice value after we sleep. */ - ts->ts_slice = sched_slice; sched_add(td, SRQ_BORING); } -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - ___ 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: aperf/mperf
[looks like I originally sent the reply only privately] on 19/11/2010 16:50 Daniel Nebdal said the following: > On Fri, Nov 19, 2010 at 4:39 PM, Andriy Gapon wrote: >> >> I am thinking about providing two APIs for this. >> >> 1. KPI >> void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); >> >> 2. Userland >> sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. >> >> But I am not sure where to put the code for both APIs. >> Adding another device under cpu seems like an overkill. >> >> Ideas? >> Thanks! > > No comment on where to put it, but one other detail: Since these are > measures since last reset, you probably want a similar > "cpu_zero_a_m_perf" call. As for how that interacts with the sysctl, > uhm ... maybe also offering a time-since-last-reset could be useful? > I have something else in mind - no reset, but you call cpu_get_a_m_perf() twice, take differences in the counters (accounting for possible overflows) and divide those deltas. In my opinion that should work. -- 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"
A big-ish machine, cannot boot
I have a large-ish marchine, a Fujitsu TX300 S6 with 2x6-core + HTT CPUs and 24 GB RAM, configured as a demo machine with lots of interesting hardware. Unfortunately, the kernel hangs on boot. The loader finishes, the twirly starts spinning but then hangs. Enabling verbose booting results in nothing new - no kernel messages at all. Any ideas? ___ 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"
new cpuid bits
Guys, I would like to add definitions for couple more useful CPUID bits, but I am greatly confused about how to name them. I failed to deduce the naming convention from the existing definitions and I am not sure how to make the names proper and descriptive. The bits in question are returned by CPUID.6 in EAX and ECX. CPUID.6 block is described by both AMD and Intel as "Thermal and Power Management (Leaf)". Bits in EAX are defined only for Intel at present, the bit in ECX is defined for both. Description/naming of the bits from the specifications: EAX[0]: Digital temperature sensor is supported if set EAX[1]: Intel Turbo Boost Technology Available EAX[2]: ARAT. APIC-Timer-always-running feature is supported if set. ECX[0]: Intel: Hardware Coordination Feedback Capability (Presence of Bits MCNT and ACNT MSRs). AMD: EffFreq: effective frequency interface. How does the following look to you? I will appreciate suggestions/comments. Thanks! Index: sys/amd64/include/specialreg.h === --- sys/amd64/include/specialreg.h (revision 215524) +++ sys/amd64/include/specialreg.h (working copy) @@ -136,6 +136,15 @@ #defineCPUID2_AESNI0x0200 /* + * Important bits in the Thermal and Power Management flags + * CPUID.6 EAX and ECX. + */ +#defineCPUTPM1_SENSOR 0x0001 +#defineCPUTPM1_TURBO 0x0002 +#defineCPUTPM1_ARAT0x0004 +#defineCPUTPM2_EFFREQ 0x0001 + +/* * Important bits in the AMD extended cpuid flags */ #defineAMDID_SYSCALL 0x0800 -- 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: www/chromium crashing whole system
On Tue Nov 16 10, Robert N. M. Watson wrote: > > On 15 Nov 2010, at 22:19, Alexander Best wrote: > > > thanks for all your help. i've recently switched to chromium 6.0.472.63 > > and so far my computer has been very stable. > > > > if i experience more lock ups i'll let you know and try to figure out a way > > to > > gain access to some more debugging data. > > I'd prefer we try to figure out why your system was crashing now -- the > kernel bug has not gone away just because Chromium is no longer triggering > it. Working around the bug means someone else gets to run into it later -- > perhaps when it's 9.0-RELEASE rather than 9-CURRENT... "GOOD" news btw: the new chromium port just crashed my system. ;) so the issue is still there. and be issue i mean the code that triggers the crash. > > Robert -- a13x ___ 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: TTY task group scheduling
On Fri, Nov 19, 2010 at 02:18:52PM +, Vincent Hoffman wrote: > On 19/11/2010 12:42, Eric Masson wrote: > > Bruce Cran writes: > > > > Hello, > > > >> Google suggests that the work was a GSoC project in 2005 on a pluggable > >> disk scheduler. > > It seems that something similar has found its way in DFlyBSD, dsched. > And indeed to FreeBSD, man gsched. Added sometime round April > http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log It's been pointed out on the list a couple times, and I've sent mail to the authors about this, that gsched breaks (very, very badly) things like sysinstall, and does other strange things like leaves trailing periods at the end of its ".sched." labels. This appears to be by design, but I'm still left thinking "?!" It's hard to discern technical innards/workings of GEOM since the documentation is so poor (and reading the code doesn't help, especially with regards to libgeom). IMHO, the gsched "stuff", as a "layer", should probably be moved into the I/O framework by default, with the functionality *disabled* by default and tunables to adjust it. That's just how I feel about it. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: aperf/mperf
On Fri, Nov 19, 2010 at 4:39 PM, Andriy Gapon wrote: > > I am thinking about providing two APIs for this. > > 1. KPI > void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); > > 2. Userland > sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. > > But I am not sure where to put the code for both APIs. > Adding another device under cpu seems like an overkill. > > Ideas? > Thanks! No comment on where to put it, but one other detail: Since these are measures since last reset, you probably want a similar "cpu_zero_a_m_perf" call. As for how that interacts with the sysctl, uhm ... maybe also offering a time-since-last-reset could be useful? -- Daniel Nebdal ___ 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: aperf/mperf
I am thinking about providing two APIs for this. 1. KPI void cpu_get_a_m_perf(u_int cpu, uint64_t *aperf, uint64_t *mperf); 2. Userland sysctl dev.cpu.N.aperf_mperf that returns two UQUAD values. But I am not sure where to put the code for both APIs. Adding another device under cpu seems like an overkill. Ideas? Thanks! -- 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: TTY task group scheduling
On 19/11/2010 12:42, Eric Masson wrote: > Bruce Cran writes: > > Hello, > >> Google suggests that the work was a GSoC project in 2005 on a pluggable >> disk scheduler. > It seems that something similar has found its way in DFlyBSD, dsched. And indeed to FreeBSD, man gsched. Added sometime round April http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log Vince > Éric Masson > ___ 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: TTY task group scheduling
Bruce Cran writes: Hello, > Google suggests that the work was a GSoC project in 2005 on a pluggable > disk scheduler. It seems that something similar has found its way in DFlyBSD, dsched. Éric Masson -- manquerait plus que les groupes soient pollués. c'est beaucoup plus grave que des plages bretonnes à deux francs qui étaient déjà polluées par ces salopards de volatiles. dieu merci, il n'y en aura bientôt plus -+- tilt in http://www.le-gnu.net : Les oiseaux sont des cons. ___ 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: TTY task group scheduling
on 18/11/2010 22:20 Julian Elischer said the following: > tty grouping is a variant of what we used to have at one stage which is > a "kernel schedulable entity group".. KSEG Or rather, I think, a concrete application of a variant of that. > the idea is that all items in a group share some characteristic and some > amount > of resources. > > We stripped the KSEG out of the picture because it really complicated the > picture. Yes, unfortunately. One can think about a number of applications for hierarchical schedulable resources. Even one-level group scheduling could be a very useful subcase. BTW, http://www.mjmwired.net/kernel/Documentation/cgroups.txt -- 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: Testing /dev/fido ?
On 19 November 2010 01:56, Sean Bruno wrote: > On Thu, 2010-11-18 at 13:17 -0800, Ivan Voras wrote: >> I have an IPMI-enabled server with BMC watchdog, and if I understand it >> correctly, /dev/fido will be attached as the result of loading ipmi.ko. >> >> Is there some easy way to test if everything works? > > I *think* that if you panic the box to the debugger, that should put the > machine into a state where the watchdog will fire right? Heh, unfortunately it seems to not work at all, in the sense that the OS (i have watchdogd running!) apparently doesn't communicate to IPMI that it's alive and IPMI resets the system out of the blue when that feature is enabled. Any ideas where to dig for problems? I have ipmi.ko loaded and watchdogd started - is there something else I should do? dmesg ipmi messages are: > dmesg |grep ipmi ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa ipmi0: IPMI device rev. 1, firmware rev. 2.2, version 2.0 ipmi0: Number of channels 2 ipmi0: Attached watchdog ___ 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: old references to vfs_mountroot_try()
On Fri Nov 19 10, Sergey Kandaurov wrote: > On 19 November 2010 02:14, Alexander Best wrote: > > hi there, > > > > vfs_mountroot_try() seems to have been removed, yet the src still contains > > three references to it: > > > > vfs_mount.c:386 > > vfs_mount.c:723 > > freebsd32_misc.c:2368 > > > > So, what about just to rename those comments to reflect function name change? that looks fine. i don't know anything about vfs, so i simply figured out that the reference to vfs_mountroot_try() was not right anymore, but couldn't find where MNT_ROOTFS is now being set. ...so its parse_mount(). :) could you commit that? cheers. alex > > Index: sys/kern/vfs_mount.c > === > --- sys/kern/vfs_mount.c(revision 215516) > +++ sys/kern/vfs_mount.c(working copy) > @@ -383,7 +383,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of nmount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > +* MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > > @@ -720,7 +720,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of mount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > +* MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > > Index: sys/compat/freebsd32/freebsd32_misc.c > === > --- sys/compat/freebsd32/freebsd32_misc.c (revision 215516) > +++ sys/compat/freebsd32/freebsd32_misc.c (working copy) > @@ -2365,7 +2365,7 @@ > * Filter out MNT_ROOTFS. We do not want clients of nmount() in > * userspace to set this flag, but we must filter it out if we want > * MNT_UPDATE on the root file system to work. > -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). > +* MNT_ROOTFS should only be set in the kernel in parse_mount(). > */ > uap->flags &= ~MNT_ROOTFS; > > -- > wbr, > pluknet -- a13x ___ 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: TTY task group scheduling
Quoting Alexander Best (from Fri, 19 Nov 2010 00:17:10 +): 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* or \ thereabouts 17:51 @ Genesys : you could kldload new ones and switch to them on the fly 17:52 @ arundel : wow. that sounds cool. too bad it didn't make it into src \ tree. by now it's probably outdated and needs to be reworked quite a bit. does anybody know something about this? I'm aware of the I/O scheduling code (which is now available at least in -current), but I do not remember CPU scheduling code from Luigi. Are you sure Genesys didn't mix up something by accident? Bye, Alexander. -- Ferengi Rule of Acquisition #123: Even a blind man can recognize the glow of latinum. -- ST: Legends of the Ferengi http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: TTY task group scheduling
On Fri, 19 Nov 2010 00:17:10 + Alexander Best wrote: > 17:51 @ Genesys : Luigi Rizzo had a plugabble scheduler back in 4.* > or \ thereabouts > 17:51 @ Genesys : you could kldload new ones and switch to them on > the fly 17:52 @ arundel : wow. that sounds cool. too bad it didn't > make it into src \ tree. by now it's probably outdated and needs to > be reworked quite a bit. > > does anybody know something about this? Google suggests that the work was a GSoC project in 2005 on a pluggable disk scheduler. -- 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: [RFC] ifconfig description support in rc.d
On 11 October 2010 14:29, Hiroki Sato wrote: > Hi, > > pluknet wrote > in : > > pl> On 27 August 2010 00:09, Doug Barton wrote: > pl> > On 08/26/2010 12:53 PM, pluknet wrote: > pl> >> > pl> >> [cc'ing current@ as rc@ looks too quite] > pl> >> > pl> >> Hi. > pl> >> > pl> >> Since ifconfig has grown to label interfaces with > pl> >> ifconfig $ifname description "foobar", what about > pl> >> to give it more life and store i/face descriptions > pl> >> semi-permanently, so they will survive between reboots? > pl> >> > pl> >> This patch adds a functionality to rc.d to label > pl> >> interfaces at boot time. > pl> >> > pl> >> Comments are welcome. > pl> > > pl> > This seems like a good addition, thanks. Please also write a patch for > pl> > rc.conf.5 to describe this new functionality and I'll be happy to > commit it. > pl> > pl> Xin Li helped me with updating rc.conf.5 (thanks!). > pl> It's included in attached patch. > (snip) > pl> >> + # ifconfig_IF_descr > pl> >> + for _if in `ifconfig -l`; do > > I think using "ifconfig -l" here is not a good idea. Setting a > description for each interface in a function invoked by ifn_start() > would be better. > > This is beacuse the netif script can be run not only at boottime but > also via devd or by hand for a specific interface. So, if the > ifnet_descr is there, "/etc/rc.d/netif start IF" does not make it > run. Since the description is a per-interface property, > "/etc/rc.d/netif start IF" should set one, and "/etc/rc.d/netif stop > IF" should clear one, IMHO. > > Also, "ifconfig -l" is not compatible with $network_interfaces, so > you need to use list_net_interface() for that purpose instead (if you > move ifnet_descr() into ifn_start() it is useless, though). > Actually, both versions were developed at the same time. This one follows "netif" approach. Somehow it was rejected by me for some reasons which I don't remember for now. That's why I didn't include it to my original message. Please, see attached. -- wbr, pluknet P.S. Google marks patches as (application/octet-stream). Bad Google. descr.rc.d.netif.patch Description: Binary data ___ 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: old references to vfs_mountroot_try()
On 19 November 2010 02:14, Alexander Best wrote: > hi there, > > vfs_mountroot_try() seems to have been removed, yet the src still contains > three references to it: > > vfs_mount.c:386 > vfs_mount.c:723 > freebsd32_misc.c:2368 > So, what about just to rename those comments to reflect function name change? Index: sys/kern/vfs_mount.c === --- sys/kern/vfs_mount.c(revision 215516) +++ sys/kern/vfs_mount.c(working copy) @@ -383,7 +383,7 @@ * Filter out MNT_ROOTFS. We do not want clients of nmount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). +* MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap->flags &= ~MNT_ROOTFS; @@ -720,7 +720,7 @@ * Filter out MNT_ROOTFS. We do not want clients of mount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). +* MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap->flags &= ~MNT_ROOTFS; Index: sys/compat/freebsd32/freebsd32_misc.c === --- sys/compat/freebsd32/freebsd32_misc.c (revision 215516) +++ sys/compat/freebsd32/freebsd32_misc.c (working copy) @@ -2365,7 +2365,7 @@ * Filter out MNT_ROOTFS. We do not want clients of nmount() in * userspace to set this flag, but we must filter it out if we want * MNT_UPDATE on the root file system to work. -* MNT_ROOTFS should only be set in the kernel in vfs_mountroot_try(). +* MNT_ROOTFS should only be set in the kernel in parse_mount(). */ uap->flags &= ~MNT_ROOTFS; -- wbr, pluknet ___ 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: TTY task group scheduling
on 19/11/2010 00:55 Daniel Nebdal said the following: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: >> On Thu, 18 Nov 2010 18:56:35 + >> Alexander Best wrote: >>> well...i tried playing back a 1080p vide files while doing >>> `make -j64 buildkernel` and FreeBSD's interactivity seems far from >>> perfect. >> >> One thing that just begs to be asked: since when decoding 1080p became >> an interactive task? >> > > Strictly speaking it isn't - but displaying it is a timing-sensitive > task that isn't CPU- or I/O-bound, and scheduling-wise that probably Well, I am not sure if I can agree about CPU-bound-ness. Depends on the exact video file, of course, but certain high-quality 1080p are very CPU intensive unless decoding is offloaded from the CPU. Depends on decoder code too. I had some videos that were CPU-bound on my Athlon II X2 250 with then-version of mplayer from ports. YMMV. -- 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: TTY task group scheduling
on 18/11/2010 20:56 Alexander Best said the following: > On Thu Nov 18 10, Matthew D. Fuller wrote: >> On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of >> Alexander Best, and lo! it spake thus: >>> >>> judging from the videos the changes are having a huge impact imo. >> >> Well, my (admittedly limited, and certainly anecdotal) experience is >> that Linux's interactive response when under heavy load was always >> much worse than FreeBSD's. So maybe that's just them catching up to >> where we already are ;) > > well...i tried playing back a 1080p vide files while doing > `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. > > it might be possible that linux'es interactivity was worse than freebsd's, > but still this patch should be evaluated for freebsd. in this particular case > it seems linux now does better than freebsd. You do realize that there are many more variables for such a test than just "1080p video" and "make -j64 buildkernel"? Let's not forget about hardware, video drivers, player capabilities, exact kind of the video (you know, 1080p alone doesn't tell much). Besides, someone might be interested in running -j64 on his 1,2,4-core desktop system, but it's definitely not me. I prefer to be reasonable. I am not saying that our scheduler (ULE) is perfect. I don't even say that it's better (in whatever comparison system) than Linux scheduler X. I say that I wouldn't spend my time improving system behavior in a scenario like this. I compile stuff very frequently (kernels, ports, world) while browsing web, reading email, doing various "desktop stuff", sometimes watching videos from the web (like e.g. trailers). On this machine/hardware I have never personally felt a need for improvements in the scheduler. And I run KDE4 with all bells and whistles enabled. YMMV. P.S. I don't discourage anyone from improving our scheduler, I even do encourage that. -- 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"
