[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?



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:
>>> Hi!
>>>
>>> I am putting upstream author Jens Axboe on CC.
>>>
>>> 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=unsta
>>>>> 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.

-- 
Jens Axboe


Reply to: