Re: TTY task group scheduling
On Thu, Nov 18, 2010 at 06:23:24PM +, Alexander Best wrote: > you think so? judging from the videos the changes are having a huge impact > imo. On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. Cheers, -- Andrew ___ 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 Nov 18, 2010, at 18:43, Julian Elischer wrote: we are part of the way there.. at least we did abstract the scheduler to the point where we have two completely different ones. you are welcome to develop a 'framework as you describe and plug it into the abstraction we already have. It may be something to suggest for the next round of Google's Summer of Code. Or perhaps part of a school project in operating systems work (master's level? eager-beaver bachelor's thesis?). Having a bit more flexibility in being able to make different components "pluggable" would help encourage the use of BSD in more research projects. And more people learning and hacking on BSD can't be a bad thing. :) ___ 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: panic: loading if_bfe after boot
On Fri, Nov 19, 2010 at 1:29 AM, Pyun YongHyeon wrote: > On Sat, Oct 30, 2010 at 09:19:06PM -0700, Pyun YongHyeon wrote: >> On Sat, Oct 30, 2010 at 5:40 PM, Paul B Mahol wrote: >> > Hi, >> > >> > Loading if_bfe module after boot hangs machine, it works/attach fine >> > from loader. >> > >> > Tell me if you need bt. >> >> Yes, I want to see the back trace. > > I think it was fixed in HEAD(r215348) and MFCed to stable/8 and > stable/7. Of course it did. Otherwise I would scream on list ;) ___ 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: panic: loading if_bfe after boot
On Sat, Oct 30, 2010 at 09:19:06PM -0700, Pyun YongHyeon wrote: > On Sat, Oct 30, 2010 at 5:40 PM, Paul B Mahol wrote: > > Hi, > > > > Loading if_bfe module after boot hangs machine, it works/attach fine > > from loader. > > > > Tell me if you need bt. > > Yes, I want to see the back trace. I think it was fixed in HEAD(r215348) and MFCed to stable/8 and stable/7. ___ 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: net.link.log_link_state_change broken?
On 11/18/10, Bjoern A. Zeeb wrote: > On Tue, 2 Nov 2010, Paul B Mahol wrote: > > Hi, > >> It appears we do not log such events anymore (at least with wlan >> devices) in console. >> >> I set this sysctl to 0 via sysctl.conf, if I set it to 1, nothing will >> change. >> >> Because I had loging disabled for very long time I encountered this >> problem just now. > > not sure. Might be, might not be. Have you further looked into this? > > I at least see: > ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, > LINK_STATE_UP); > ./net80211/ieee80211_freebsd.c: if_link_state_change(ifp, > LINK_STATE_DOWN); That part is not problematic, klog part is. Messages of link state changes are not available in console but are available in klog and in console once you open it with cat. Reading comment it appears that logic is inverted in code. ___ 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 Nov 18 10, Julian Elischer wrote: > On 11/18/10 3:37 PM, Alexander Best wrote: > >On Fri Nov 19 10, Daniel Nebdal wrote: > >>On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev > >>wrote: > >>>On Thu, 18 Nov 2010 18:56:35 + > >>>Alexander Best wrote: > >>> > 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. > >>>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 > >>makes it more like the "fast response when woken up" interactive tasks > >>than a CPU-bound non-interactive process. > >>Decoding it into another file on the disk is in the latter category, > >>of course - but I don't think that's what he meant. :) > >> > >>More on topic - while this was a tiny patch for Linux, it seems like > >>it would take more work for us, since I don't believe either of the > >>schedulers handles task groups in the required way. The linux patch > >>was just "create task groups automatically", since they already had > >>some suitable logic for scheduling based on task groups in their CFS > >>scheduler. We would have to (re-)add that first, which is non-trivial. > >personally i think freebsd would hugely benefit from a scheduler framework > >such as geom/gsched, where it's easy to switch between various algorithms. > > > >that way it be much easier to try out new concepts without having to write > >a > >completely new scheduler. > > we are part of the way there.. > > at least we did abstract the scheduler to the point where > we have two completely different ones. > you are welcome to develop a 'framework as you describe and plug it into > the abstraction we already have. 17:49 @ arundel : also looking at the svn log shows that still a lot of \ commits happen to sched_4bsd. so it's defenately not being abbandoned. in \ fact there might be situations where it performs better than sched_ule. 17:50 @ arundel : i'm looking forward to a scheduler which looks sorta like \ geom and enables you to plugin addition plugins with different scheduling \ algorithms. :) 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 sorry. i'd really love to contribute some code, but my programing skills are pretty scrappy. ;) it would probably take me 20 years to figure out the current sched code. cheers. alex > > >cheers. > >alex > > > >> > >>-- > >>Daniel Nebdal -- 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 11/18/10 3:37 PM, Alexander Best wrote: On Fri Nov 19 10, Daniel Nebdal wrote: On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: On Thu, 18 Nov 2010 18:56:35 + Alexander Best wrote: 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. 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 makes it more like the "fast response when woken up" interactive tasks than a CPU-bound non-interactive process. Decoding it into another file on the disk is in the latter category, of course - but I don't think that's what he meant. :) More on topic - while this was a tiny patch for Linux, it seems like it would take more work for us, since I don't believe either of the schedulers handles task groups in the required way. The linux patch was just "create task groups automatically", since they already had some suitable logic for scheduling based on task groups in their CFS scheduler. We would have to (re-)add that first, which is non-trivial. personally i think freebsd would hugely benefit from a scheduler framework such as geom/gsched, where it's easy to switch between various algorithms. that way it be much easier to try out new concepts without having to write a completely new scheduler. we are part of the way there.. at least we did abstract the scheduler to the point where we have two completely different ones. you are welcome to develop a 'framework as you describe and plug it into the abstraction we already have. cheers. alex -- 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: TTY task group scheduling
On Fri Nov 19 10, Daniel Nebdal wrote: > On Fri, Nov 19, 2010 at 12:06 AM, Alexander Kabaev wrote: > > On Thu, 18 Nov 2010 18:56:35 + > > Alexander Best wrote: > > > >> 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. > > > > 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 > makes it more like the "fast response when woken up" interactive tasks > than a CPU-bound non-interactive process. > Decoding it into another file on the disk is in the latter category, > of course - but I don't think that's what he meant. :) > > More on topic - while this was a tiny patch for Linux, it seems like > it would take more work for us, since I don't believe either of the > schedulers handles task groups in the required way. The linux patch > was just "create task groups automatically", since they already had > some suitable logic for scheduling based on task groups in their CFS > scheduler. We would have to (re-)add that first, which is non-trivial. personally i think freebsd would hugely benefit from a scheduler framework such as geom/gsched, where it's easy to switch between various algorithms. that way it be much easier to try out new concepts without having to write a completely new scheduler. cheers. alex > > > -- > Daniel Nebdal -- 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 Thu, Nov 18, 2010 at 3:12 PM, Steve Kargl wrote: > On Thu, Nov 18, 2010 at 10:59:43PM +, Alexander Best wrote: >> >> well i did exactly what they did in the video. watch a 1080p video and move >> the output window around while compiling the kernel. >> > > It is trivial to bring ULE to its knees. If you > have N cores then all you need is N+1 cpu intensive > task. The issue has been known for a few years. I/O intensive tasks don't help either though. Things tend to get choppy whenever I'm doing something like update from svn and doing something a bit more interactive like use firefox (and scroll... for instance gmail seems to be a pig in this area -- heh), vlc is a little less painful, etc. I wonder if the issue isn't necessarily tasks but more or less locking. firefox uses a lot of threads and file based mutexes according to what I've seen with top and ps (please correct me if I'm wrong). firefox also has a tendency with the nvidia-driver (I know... blobs are bad) to produce funky artifacts on the screen (again, when scrolling on gmail, dealing with flash, etc) or certain bits don't redraw properly (text when scrolling ends up ghosting on multiple lines until I force a redraw with the cursor or by scrolling back over that section of text). I'm sure there are a lot of performance issues within FreeBSD and opensource desktop software that needs to be properly worked out on a case by case basis, so I think that writing everything off as awesome and working better with one magic patch is unlikely. Besides, Linux has a more complicated scheduler than FreeBSD does. 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"
old references to vfs_mountroot_try()
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 cheers. alex -- 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 Thu, Nov 18, 2010 at 10:59:43PM +, Alexander Best wrote: > > well i did exactly what they did in the video. watch a 1080p video and move > the output window around while compiling the kernel. > It is trivial to bring ULE to its knees. If you have N cores then all you need is N+1 cpu intensive task. The issue has been known for a few years. http://freebsd.monkey.org/freebsd-current/200807/msg00278.html http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg65839.html -- Steve ___ 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 Nov 18 10, Alexander Kabaev wrote: > On Thu, 18 Nov 2010 18:56:35 + > Alexander Best wrote: > > > 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. > > One thing that just begs to be asked: since when decoding 1080p became > an interactive task? well i did exactly what they did in the video. watch a 1080p video and move the output window around while compiling the kernel. cheers. alex > > -- > Alexander Kabaev -- 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 12:06 AM, Alexander Kabaev wrote: > On Thu, 18 Nov 2010 18:56:35 + > Alexander Best wrote: > >> 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. > > 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 makes it more like the "fast response when woken up" interactive tasks than a CPU-bound non-interactive process. Decoding it into another file on the disk is in the latter category, of course - but I don't think that's what he meant. :) More on topic - while this was a tiny patch for Linux, it seems like it would take more work for us, since I don't believe either of the schedulers handles task groups in the required way. The linux patch was just "create task groups automatically", since they already had some suitable logic for scheduling based on task groups in their CFS scheduler. We would have to (re-)add that first, which is non-trivial. -- 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: TTY task group scheduling
On Thu, 18 Nov 2010 18:56:35 + Alexander Best wrote: > 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. One thing that just begs to be asked: since when decoding 1080p became an interactive task? -- Alexander Kabaev signature.asc Description: PGP signature
Re: ideas for _PSD/_CSD/_TSD
On 11/18/2010 11:09 AM, Andriy Gapon wrote: > I am trying to solicit some architectural/design ideas for implementing logic > that > would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. > Well, I am primarily interested in _PSD, but I think that some general > principles > could be shared. > > In simple terms. > Currently we do only the "global" P-state management. cpufreq advertises a > common > set of frequencies/P-states and a single P-state/frequency is set on all > (logical) > processors by e.g. powerd based on global system load. > The downsides are obvious, I think. > > Modern systems can provide _PSD method which describes grouping of logical > processors into P-state domains and nature of dependency between the > processors in > the domain. E.g. on some systems putting a single processor from the domain > into > a Px state results in all the processors being put into that state. On other > systems, all processors have to be put into the same state for it to become > effective. On yet other systems there could be no coordination required > between > the processors (even when they are all cores in the same package), so each > would > be placed in its own domain. > > I think that this issue may get more prominence because of the new > technologies > that combine power saving with "turbo boosting". E.g. there could be a > technology > where some processor's performance would only be boosted if other processors > are > at or above some state Pt. With current cpufreq design we would not be able > to > take an advantage of that, because we always put all the processors into the > same > state. As you can see from the codebase, cpufreq was designed with this model in mind. I spent a lot of work adding the cpu devices to newbus in order to have cpufreq attach per-cpu. Each instance has its own dev.cpu.X.freq setting. Of course, there weren't any asymmetrical CPU Px states back then so calculation of levels is shared as you point out. But since it's done in cpufreq attach(), it is easy to make that independent while still merging states with global settings (e.g., p4tcc relative levels that apply system-wide, not per-cpu). What you want is to have a flag that indicates if Px states are global or not. If global, you can still attach a cpufreq device to each cpu but make changing any of their settings loop through changing all cpu settings equally. This is how it currently works. If the flag is false, then only apply a setting to the device it was received on. -- 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: VIMAGE: Freed UMA keg was not empty
"Bjoern A. Zeeb" a écrit > On Thu, 18 Nov 2010, Thierry Herbelot wrote: > > "Bjoern A. Zeeb" a écrit > > > >> On Wed, 17 Nov 2010, Thierry Herbelot wrote: > >>> As promised, here are the full logs (in attachment) > >>> > >>> This is a serial console log showing the command loop that triggers the > >>> bug on a debug kernel and ensuing DDB session. > >>> > >>> the obvious problem line is : > >>> routetbl 2684 303890K 3469 > >>> > >>> (further tests showed an increase of the routetbl malloc zone by > >>> 4MBytes for each vnet jail creation/destruction cycle) > >> > >> Hmm, I had fixed that (somewhere). I'll see where the patch went. You > >> are on 8.1-RELEASE or -STABLE? > > > > This will be for a -release, thus 8.1 for now, but we will switch to 8.2 > > ASAP > > Well wait; I am not sure the changes are in SVN at all. I'll get back > to you. OK for us : we are still in the process of deploying the solution, but still we will test any patch you can forward ;-) TfH > > /bz ___ 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 Wed, 17 Nov 2010 21:30:13 -0800, Julian Elischer wrote: > On 11/17/10 12:15 PM, Marcin Wisnicki wrote: >>> >> Probably not. I thought about it a bit more and realized that you will >> miss state of cpu registers which is rather important. >> >> How does debugging over firewire work if it only has access to host RAM >> ? > > registers are saved to ram as part of exception handling.. > So I guess it means it's not possible to debug complete lockup (caused by driver) where no panic() occured ? ___ 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/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. ___ 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/18/10 19:28, 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 ;) Wishful thinking? ___ 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"
Testing /dev/fido ?
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? ___ 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: VIMAGE: Freed UMA keg was not empty
On Thu, 18 Nov 2010, Thierry Herbelot wrote: "Bjoern A. Zeeb" a écrit On Wed, 17 Nov 2010, Thierry Herbelot wrote: As promised, here are the full logs (in attachment) This is a serial console log showing the command loop that triggers the bug on a debug kernel and ensuing DDB session. the obvious problem line is : routetbl 2684 303890K 3469 (further tests showed an increase of the routetbl malloc zone by 4MBytes for each vnet jail creation/destruction cycle) Hmm, I had fixed that (somewhere). I'll see where the patch went. You are on 8.1-RELEASE or -STABLE? This will be for a -release, thus 8.1 for now, but we will switch to 8.2 ASAP Well wait; I am not sure the changes are in SVN at all. I'll get back to you. /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html___ 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: VIMAGE: Freed UMA keg was not empty
"Bjoern A. Zeeb" a écrit > On Wed, 17 Nov 2010, Thierry Herbelot wrote: > > As promised, here are the full logs (in attachment) > > > > This is a serial console log showing the command loop that triggers the > > bug on a debug kernel and ensuing DDB session. > > > > the obvious problem line is : > > routetbl 2684 303890K 3469 > > > > (further tests showed an increase of the routetbl malloc zone by 4MBytes > > for each vnet jail creation/destruction cycle) > > Hmm, I had fixed that (somewhere). I'll see where the patch went. You > are on 8.1-RELEASE or -STABLE? This will be for a -release, thus 8.1 for now, but we will switch to 8.2 ASAP Thanks TfH > > /bz ___ 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/18/10 10:55 AM, 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. tty grouping is a variant of what we used to have at one stage which is a "kernel schedulable entity group".. KSEG 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. Regards, Lucius ___ 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: TTY task group scheduling
On Thu, Nov 18, 2010 at 10:56 AM, Alexander Best wrote: > 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. Maybe I'm just a lowly user and don't fully understand the issue, but isn't this the whole reason for having /usr/bin/nice installed? As in, if you don't want your make job to hog resources, then use nice to run it in the background. How does the work on the geom_sched (for I/O scheduling) play into this? Am I missing something fundamental to the issue in question? Also, does this really need to be cross-posted to -current, -hackers, and -performance? -- Freddie Cash fjwc...@gmail.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 Nov 18, 2010, at 10:23 AM, Alexander Best wrote: > On Thu Nov 18 10, Andriy Gapon wrote: >> on 18/11/2010 13:04 O. Hartmann said the following: >>> 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. >> >> Well, I think that those improvements apply only to a very specific usage >> pattern >> and are greatly over-hyped. > > you think so? judging from the videos the changes are having a huge impact > imo. > > cheers. > alex > > btw: i posted a similar thread on freebsd-backers@, but nobody seemed > interested in it. subject line is "sched_autogroup_enabled". I attempted to find reliable benchmarks or even an idea as to what they thought they were measuring, because a sentence like the following: Tests done by Mike show the maximum latency dropping by over ten times and the average latency of the desktop by about 60 times. ...isn't mathematically possible, I'm pretty sure. Frankly, I'm also turned off by the attempt to popup a full page ad in addition to the rest of the advertising content which surrounds what is nominally supposed to be the real content. That doesn't mean there is anything wrong with the patch or the notion of adjusting the scheduler, but I don't see any value added from these phoronix.com links. 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: TTY task group scheduling
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 ___ 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... i'm really sorry, but this is a problem ~ 90% of desktop users have: 1) we only have 1 computer 2) we can't access our computer via some other box via ssh or something 3) we don't have serial cables or firewire cables so it seems in this situation a complete deadlock *cannot* be analyzed. the idea of dumping the memory to a usb stick after a hard reboot thus seems so attractive to users like me. still the question is: how can we use such a complete memory dump? i don't think it's as easy as loading it into kdb, is it? cheers. alex > > 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"
ideas for _PSD/_CSD/_TSD
I am trying to solicit some architectural/design ideas for implementing logic that would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains. Well, I am primarily interested in _PSD, but I think that some general principles could be shared. In simple terms. Currently we do only the "global" P-state management. cpufreq advertises a common set of frequencies/P-states and a single P-state/frequency is set on all (logical) processors by e.g. powerd based on global system load. The downsides are obvious, I think. Modern systems can provide _PSD method which describes grouping of logical processors into P-state domains and nature of dependency between the processors in the domain. E.g. on some systems putting a single processor from the domain into a Px state results in all the processors being put into that state. On other systems, all processors have to be put into the same state for it to become effective. On yet other systems there could be no coordination required between the processors (even when they are all cores in the same package), so each would be placed in its own domain. I think that this issue may get more prominence because of the new technologies that combine power saving with "turbo boosting". E.g. there could be a technology where some processor's performance would only be boosted if other processors are at or above some state Pt. With current cpufreq design we would not be able to take an advantage of that, because we always put all the processors into the same state. 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 Thu Nov 18 10, Rob Farmer wrote: > On Thu, Nov 18, 2010 at 10:39, Chuck Swiger wrote: > > Frankly, I'm also turned off by the attempt to popup a full page ad in > > addition to the rest of the advertising content which surrounds what is > > nominally supposed to be the real content. That doesn't mean there is > > anything wrong with the patch or the notion of adjusting the scheduler, but > > I don't see any value added from these phoronix.com links. > > Most stuff on Phoronix is of dubious value, and they have outright > lied about stuff in the past, in order to drum up advertising business > (such as Steam on Linux, which Value has consistently said isn't > happening). so we need a trusted source to check whether the impact of the ~200 line patch as claimed by phoronix remains valid. can anybody test this? or provide links to independant benchmark results? cheers. alex > > -- > Rob Farmer -- 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: Panic with vfs.root.mountfrom=nfs on CURRENT (was Re: [patch] functional prototype of root mount enhancement)
On Nov 17, 2010, at 4:10 PM, Garrett Cooper wrote: > > Hi Marcel, >Do you have any examples that use nfs rootfs's out of the box that > work with the new logic that don't involve creating an mfsroot? I keep > on running into this error with vfs.root.mountfrom=nfs (previously on > CURRENT it would just try to mount nfs via nfs_mount in the NFS client > without any complaints): The syntax is $fs:$dev. For NFS $dev can be empty, leaving "nfs:". The problem is with there not being a colon after nfs in your case. This could be a change in behaviour from before, which probably needs a fix. I'll look into it... >I don't run into this error when I unset this variable sometimes > (it boots up multiuser and all is happy, hunky dory when I manually > query this variable from the pxeboot loader, but not when I don't... > it's weird). >It seems to ignore the directives in mount.conf: > > # cat mount.conf > .onfail continue > .ask The filename to use is "/.mount.conf". Notice the period. -- 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: TTY task group scheduling
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. cheers. alex > > > -- > Matthew Fuller (MF4839) | fulle...@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ >On the Internet, nobody can hear you scream. -- 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 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 ;) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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, Nov 18, 2010 at 10:39, Chuck Swiger wrote: > Frankly, I'm also turned off by the attempt to popup a full page ad in > addition to the rest of the advertising content which surrounds what is > nominally supposed to be the real content. That doesn't mean there is > anything wrong with the patch or the notion of adjusting the scheduler, but I > don't see any value added from these phoronix.com links. Most stuff on Phoronix is of dubious value, and they have outright lied about stuff in the past, in order to drum up advertising business (such as Steam on Linux, which Value has consistently said isn't happening). -- Rob Farmer ___ 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 Nov 18 10, Andriy Gapon wrote: > on 18/11/2010 13:04 O. Hartmann said the following: > > 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. > > Well, I think that those improvements apply only to a very specific usage > pattern > and are greatly over-hyped. you think so? judging from the videos the changes are having a huge impact imo. cheers. alex btw: i posted a similar thread on freebsd-backers@, but nobody seemed interested in it. subject line is "sched_autogroup_enabled". > > P.S. What is the due time, BTW? > > -- > Andriy Gapon -- 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: aperf/mperf
On Nov 18, 2010, at 07:32 , Andriy Gapon wrote: > on 18/11/2010 05:53 George Neville-Neil said the following: >> >> On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: >> >>> >>> Many modern processors provide APERF and MPERF MSRs which allow to easily >>> and >>> reliable calculate average CPU performance level over some interval of time. >>> This also allows to notice things like performance boost, which is generally >>> hidden from software. >>> What would be a proper place to add code that would measure APERF/MPERF >>> ratio? >>> When should trigger such a measurement and over what interval? >>> Ideas? >> >> Can you point me at documentation for this? This sounds a lot like >> hwpmc(4) and I wonder if we can make these available in the same way. > > Actually it feels more cpufreq-ish to me. > This feature is documented in, e.g., Intel Software Developer's Manual volume > 3A, > section 14.2 P-STATE HARDWARE COORDINATION. Ah, yes, quite right on cpufreq etc. Thanks for the documentation pointer though. Best, George ___ 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 18/11/2010 15:38 Daniel Nebdal said the following: > Just for the sake of gathering information here: > What they offer are two (64-bit, wrapping) counters; one that > increases at a constant rate, and one that increases in proportion to > the current performance of the CPU, so that APERF/MPERF = fraction of > max possible performance the CPU has offered since the last time the > counters were zeroed. Intel specifically suggests multiplying that > with the observed CPU load over the same time period to get an > absolute CPU load number, and using that to pick a suitable P-state. > > On a tangent, I wonder if you can get APERF>MPERF if you're using an > i5/i7 and their dynamic/automatic overclocking kicks in? Yes, I believe so. At the very least AMD explicitly documents that to be the case when Core Performance Boost feature is activated. > As for what to do with it, it sounds like it would make sense as an > alternate data source for powerd? Yes, indeed. -- 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: aperf/mperf
On Thu, Nov 18, 2010 at 2:32 PM, Andriy Gapon wrote: > on 18/11/2010 05:53 George Neville-Neil said the following: >> >> On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: >> >>> >>> Many modern processors provide APERF and MPERF MSRs which allow to easily >>> and >>> reliable calculate average CPU performance level over some interval of time. >>> This also allows to notice things like performance boost, which is generally >>> hidden from software. >>> What would be a proper place to add code that would measure APERF/MPERF >>> ratio? >>> When should trigger such a measurement and over what interval? >>> Ideas? >> >> Can you point me at documentation for this? This sounds a lot like >> hwpmc(4) and I wonder if we can make these available in the same way. > > Actually it feels more cpufreq-ish to me. > This feature is documented in, e.g., Intel Software Developer's Manual volume > 3A, > section 14.2 P-STATE HARDWARE COORDINATION. > Just for the sake of gathering information here: What they offer are two (64-bit, wrapping) counters; one that increases at a constant rate, and one that increases in proportion to the current performance of the CPU, so that APERF/MPERF = fraction of max possible performance the CPU has offered since the last time the counters were zeroed. Intel specifically suggests multiplying that with the observed CPU load over the same time period to get an absolute CPU load number, and using that to pick a suitable P-state. On a tangent, I wonder if you can get APERF>MPERF if you're using an i5/i7 and their dynamic/automatic overclocking kicks in? As for what to do with it, it sounds like it would make sense as an alternate data source for powerd? -- 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: TTY task group scheduling
on 18/11/2010 13:04 O. Hartmann said the following: > 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. Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. P.S. What is the due time, BTW? -- 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: immediate panic in vm
on 18/11/2010 00:41 Li, Qing said the following: > Building kernel on 8.1-RELEASE should not require a buildworld, right ? > > Or there have been changes committed since that would mandate a > buildworld? See UPDATING entry 20100915 (for head). Sorry for the inconvenience. -- 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: aperf/mperf
on 18/11/2010 05:53 George Neville-Neil said the following: > > On Nov 16, 2010, at 09:37 , Andriy Gapon wrote: > >> >> Many modern processors provide APERF and MPERF MSRs which allow to easily and >> reliable calculate average CPU performance level over some interval of time. >> This also allows to notice things like performance boost, which is generally >> hidden from software. >> What would be a proper place to add code that would measure APERF/MPERF >> ratio? >> When should trigger such a measurement and over what interval? >> Ideas? > > Can you point me at documentation for this? This sounds a lot like > hwpmc(4) and I wonder if we can make these available in the same way. Actually it feels more cpufreq-ish to me. This feature is documented in, e.g., Intel Software Developer's Manual volume 3A, section 14.2 P-STATE HARDWARE COORDINATION. -- 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 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-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: VIMAGE: Freed UMA keg was not empty
On Wed, 17 Nov 2010, Thierry Herbelot wrote: As promised, here are the full logs (in attachment) This is a serial console log showing the command loop that triggers the bug on a debug kernel and ensuing DDB session. the obvious problem line is : routetbl 2684 303890K 3469 (further tests showed an increase of the routetbl malloc zone by 4MBytes for each vnet jail creation/destruction cycle) Hmm, I had fixed that (somewhere). I'll see where the patch went. You are on 8.1-RELEASE or -STABLE? /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ 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"
