Date: Tue, 12 Mar 2013 01:22:50 +0400 From: Lev Serebryakov <lev@serebryakov.spb.ru> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org Subject: Re: Unmapped buffers: to be merged in several days Message-ID: <1106238192.20130312012250@serebryakov.spb.ru> In-Reply-To: <20130311211158.GE3794@kib.kiev.ua> References: <20130311091852.GR3794@kib.kiev.ua> <86k3pe1cl3.fsf@ds4.des.no> <20130311182454.GX3794@kib.kiev.ua> <329178079.20130312010425@serebryakov.spb.ru> <20130311211158.GE3794@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Konstantin. You wrote 12 =CD=C1=D2=D4=C1 2013 =C7., 1:11:58: >> KB> If the class does need to access the bio data, to be marked >> KB> unmapped-processing, the class should be rewritten. Now, the class >> KB> should verify is the bio passed is mapped or not, and process the pa= ges >> KB> passed in the bio_ma array instead of bio_data. The involved example= is >> KB> sys/dev/md/md.c. >> Will GEOM class, which needs to touch data (like raid3 or my off-tree >> raid5), benefit from conversion, compare to generic mechanism, >> provided for not-converted by your patch? KB> First, what do you mean by 'benefit'. Answer would obviously depend KB> on the criteria. When you did this work (unmapped buffers) you had some meaning of `benefit' for whole system (FreeBSD) in mind, do you? I don't think, you do such complex work to do things worse, not better :) As far as I understand, this code significantly decrease TLB shoot-out for disk-intensive tasks in mult-core/CPU systems (and that leads to better I/O and overall system performance), at cost of more complex code in some places. Am I right? So, my question could be re-formulated in this framework like this: could be custom code in GEOM class (but such, that provide access to every data byte in every BIO) less stressful for system / faster than generic code, provided by you in GEOM framework for old classes? KB> Second, I do not think that any wizard can usefully answer this questio= n, KB> for usual criteria like speed or code maintanability. But you have answer for YOUR code, right? You could predict behavior of "generic" code for GEOMs without proper flag (you've wrote this code, after all!) and "reasonable" code, which should be written by GEOM class author for GEOM class, which need touch every byte in BIO buffer. I don't think, here is many variants of such code exists, am I right? KB> FWIW, I tried to get an Intel documentation for IOAT engine which should KB> allow to perform the XOR checksumming of the unmapped buffers, suitable KB> for e.g. hardware-assisted software raid5, but did not succeeded. :-( --=20 // Black Lion AKA Lev Serebryakov <lev@serebryakov.spb.ru>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1106238192.20130312012250>