Date: Fri, 3 Aug 2012 17:26:03 -0400 From: John Baldwin <jhb@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: current@freebsd.org, Mike Tancsa <mike@sentex.net> Subject: Re: [PATCH] Add locking to twe(4) so it no longer uses Giant Message-ID: <201208031726.03652.jhb@freebsd.org> In-Reply-To: <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com> References: <201208031418.57941.jhb@freebsd.org> <501C37D3.5040704@sentex.net> <9C0F7DB1-E75B-42A9-90A4-22599F99E15E@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, August 03, 2012 5:17:09 pm Garrett Cooper wrote: > On Aug 3, 2012, at 1:42 PM, Mike Tancsa wrote: > > > On 8/3/2012 3:39 PM, John Baldwin wrote: > >> On Friday, August 03, 2012 2:56:00 pm Kevin Oberman wrote: > >>> I'll try to find time to try it later today, but I'm in the middle of > >>> budget wrangling and I can't make any promises. > >>> > >>> Before I try, will these patches apply to the twe driver in > >>> 9.1-PRERELEASE? My system with twe was updated to RELENG_9 on July 18. > >>> I really don't have time to install current right now. > >> > >> I believe the patches should apply fine on 8 and 9. If you use it on 8 or 9 > >> please make sure to enable INVARIANTS and INVARIANT_SUPPORT at least for > >> initial testing. Thanks! > > > > Seems to apply to RELENG_9 just fine. Are there any stress tests you > > suggest I run that might expose some bugs ? The machine is not > > production yet, so its ok to crash it. > > Looking really quickly at the patch, it looks like most of the locking changes are made around management pieces, and not data handling pieces (but I might have missed something). No, it changes those paths, too. There just aren't many of them. All the data enters through twed_strategy() and leaves via twed_intr() (invoked from twe_intr()). > If there's a tool for poking at the drives/controller, I would use that, plus camcontrol. Of course you want a data intensive workload (iometer/iozone/xdd with async and sync mode, random reads and sequential reads, etc), and maybe resort to manual testing like pulling drives (power, data) if you don't mind creating failures. If you have some failed/failing drives kicking around, that would be a good test as well (see that all/some of the failure paths are properly stimulated). 3dm2 testing would be good for the ioctl handling, but the most critical tests are basic I/O. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201208031726.03652.jhb>