Date: Tue, 29 May 2012 21:12:26 +0100 From: Attilio Rao <attilio@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org, Alexander Motin <mav@freebsd.org> Subject: Re: ULE/sched issues on stable/9 - why isn't preemption occuring? Message-ID: <CAJ-FndC2FBFdxkZkOZw-MdJo4Qox5D4KODSFpHF5A3w5J98wUg@mail.gmail.com> In-Reply-To: <CAJ-VmomWV2XibSNSr5Mfh7mpKsWrX5GKsNfU9iq7TO6%2BKxxQhw@mail.gmail.com> References: <CAJ-VmomWV2XibSNSr5Mfh7mpKsWrX5GKsNfU9iq7TO6%2BKxxQhw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/5/29 Adrian Chadd <adrian@freebsd.org>: > Hi Alexander and others, > > I've been tinkering with ath(4) IO scheduling and taskqueues. In order > to get proper "in order" TX IO occuring, I've placed ath_start() into > a taskqueue so now whenever ath_start() is called, it just schedules a > taskqueue entry to run. > > However, performance is worse. :-) > > Here's a schedgraph trace. > > http://people.freebsd.org/~adrian/ath/ktr.4-ath-iperf-using-taskqueue-for-tx.ktr.gz > > I've thrown this through schedgraph.py on stable/9 and I've found some > rather annoying behaviour. It seems that the ath0 taskqueue stays in > the "runq add" state for quite a long time (1.5ms and longer) because > something else is going on on CPU #0. > > I'm very confused about what's going on. I'd like a hand trying to > figure out why the schedgraph output is the way it is. What I would usually do for this cases, is to patch your kernel with more KTR traces (handmade class, add a fictious KTR class after KTR_BUF) in the interested code paths to log why your task is not really scheduled. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndC2FBFdxkZkOZw-MdJo4Qox5D4KODSFpHF5A3w5J98wUg>