Am Freitag, 26. August 2011 schrieb Nobuhiro Iwamatsu: > Hi, Hi!
> 2011/8/26 Jens Axboe <ax...@kernel.dk>: > > On 2011-08-25 18:47, Martin Steigerwald wrote: > >> Am Donnerstag, 25. August 2011 schrieb Jens Axboe: > >>> On 2011-08-25 10:33, Martin Steigerwald wrote: [...] > >>>> Am Donnerstag, 25. August 2011 schrieb Nobuhiro Iwamatsu: > >>>>> Hi, > >>>> > >>>> [...] > >>>> > >>>>> 2011/8/3 Martin Steigerwald <m...@teamix.de>: > >>>>>> Hello Nobuhiro, Paul, hello Debian SuperH maintainers, hello > >>>>>> Jens, > >>>>>> > >>>>>> I am seeking information on the current status regarding > >>>>>> > >>>>>> Please support sh4 > >>>>>> http://bugs.debian.org/561891 > >>>>>> > >>>>>> and eventually help in resolving it if it has not already been > >>>>>> resolved. > >>>>>> > >>>>>> When I am reading > >>>>>> > >>>>>> http://buildd.debian-ports.org/status/package.php?p=fio&suite=un > >>>>>> sta bl e > >>>>>> > >>>>>> correctly, then fio 1.50-1 has been build 167d before on buildd > >>>>>> kongou. > >>>>>> > >>>>>> So is this issue resolved? > >>>>>> > >>>>>> If not, please offer help. There is a partial patch mentioned > >>>>>> earlier in the bug report. > >>>>> > >>>>> By this method, we cannot support both SH4 and SH4A. When we > >>>>> build with machine of SH4A, a binary to work only in SH4A is > >>>>> built. Because Debian SH team are supporting sh4 and sh4a in one > >>>>> binary, this becomes the problem. > >>>>> And this is a problem peculiar to Debian. It will not become the > >>>>> problem in other distribution. (e.g., Gentoo) > >>>>> It is necessary to check whether you do not do it whether we > >>>>> support synco when we support both CPU's when we execute > >>>>> *_barrier. I think that this has a big overhead. > >>>>> > >>>>> I attached quick hack patch. > >>>> > >>>> Jens, what do you think about such a patch? Please advice. > >>>> > >>>> Nobuhiro, where do you think comes the big overhead from? In your > >>>> patch you check once at beginning for sinco capability. Do you > >>>> refer to the if statement you added in arch/arch-sh.h? > >>>> > >>>> Ciao, > >>> > >>> How about something like the below, it's a bit more cleanly > >>> implemented? It still has the branch overhead per memory barrier, > >>> but I would not worry about that too much. > >> > >> Well sounds fine to me - not being into coding that much. If wanted > >> I can include the patch into my debian package git repository for > >> you SuperH folks to try out. Tell me, if you would like that. > > > > It's already in fio -git. > > > >> Jens, what would be a good workload to test for any overhead issues? > >> Small blocksizes? I do not find any references to memory barriers > >> in fio´s documentation. > > > > Barriers are only used for verify workloads, and file locking. Both > > are expensive on the CPU side, so an extra branch for a barrier will > > be long in the noise. I would not worry about it. > > Looks good for me your patch. Thank you. > > However, I take this change to other CPU's and am effective? > The patch which I sent is a change peculiar to Debian. > It is originally an unnecessary change. > It is nice that you take in this patch,; but for exclusive use of > Debian if seem to be patched, should manage it in Debian. I can take it as patch in the debian package as well, Jens, if you prefer not to include it upstream. But I guess you have no problem with including it, since you have already done so. Please tell me if otherwise. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org