[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#561891: Bug 561891: Is FTBFS for fio on SuperH (sh4) resolved?



Am Freitag, 26. August 2011 schrieb Nobuhiro Iwamatsu:
> Hi,

Hi!

> 2011/8/26 Jens Axboe <axboe@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 <ms@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


Reply to: