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:
>>>> Hi!
>>>>
>>>> I am putting upstream author Jens Axboe on CC.
>>>>
>>>> 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=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.
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.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
