Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking

On 04.09.2013 15:45, Nathan Whitehorn wrote:
> On 09/04/13 02:01, Alexander Motin wrote:
>> On 04.09.2013 00:48, Olivier Cochard-Labbé wrote:
>>> On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo
>>> <outbackdingo_at_gmail.com> wrote:
>>>> Can anyone confirm how well tested/stable this patch set might be?? if
>>>> theres positive input i have a zoo of dev machines i could load it
>>>> on, to
>>>> help further it.
>>>> Just checking to see how widely its been tested,
>>>
>>> I've installed this patch on 3 differents machines there status after
>>> about 12hours:
>>> - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big
>>> zraid (LSI MegaSAS Gen2 controller): Used for generating package with
>>> poudriere… no probleme since;
>>> - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in
>>> gmirror: Used for generating package with poudriere too… no probleme
>>> since;
>>
>> I've forgot to mention, but GEOM direct dispatch is now active only on
>> x86 because GET_STACK_USAGE macro now defined only there and I wanted
>> to stay on a safe side. On other archs GEOM works in old queued way.
>> Somebody should port that small macro to other archs. But that is
>> still interesting data point. Thanks.
>
> Could you describe what this macro is supposed to do so that we can do
> the porting work?

It supposed to report total and used stack sizes for current thread. I 
suppose that it will be equal for the most archs, but better somebody 
familiar with each one looked on it. The macro itself is not new. It is 
for years used in Netgraph for equivalent purpose.

-- 
Alexander Motin