Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jul 2010 20:27:56 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        =?UTF-8?B?TWFyaXVzIE7DvG5uZXJpY2g=?= <marius@nuenneri.ch>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-geom@freebsd.org
Subject:   Re: Hyperactive g_event thread
Message-ID:  <4C4F171C.9010106@FreeBSD.org>
In-Reply-To: <AANLkTikvV4oymBBA%2B_0zbzd_edS8dRfqqJRODE0989%2Bn@mail.gmail.com>
References:  <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <AANLkTi=uRPV2T0=t_1s=Jc4PmBtai=__HqhCtYpiDdTQ@mail.gmail.com> <AANLkTikvV4oymBBA%2B_0zbzd_edS8dRfqqJRODE0989%2Bn@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Marius NĂ¼nnerich wrote:
> On Tue, Jul 27, 2010 at 18:07, Marius NĂ¼nnerich <marius@nuenneri.ch> wrote:
>> On Tue, Jul 27, 2010 at 16:38, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>>> In message <4C4ED619.7050305@FreeBSD.org>, Alexander Motin writes:
>>>> Poul-Henning Kamp wrote:
>>>> I have already removed alike timeouts on up/down threads and it indeed
>>>> was safe there. But are you really sure about this specific case? Cause
>>>> I'm not. Up/down threads using msleep and checking lack of work after
>>>> dropping/grabbing lock. Event thread instead does several tasks, drops
>>>> lock few times between them and uses tsleep(). I would say there should
>>>> be a bunch of race conditions.
>>> Quite likely, I didn't say it would be a trivial thing to remove
>>> that workaround :-)
>>
>> I was running with a patch that removed the timeout for a while like 2
>> years ago. Albeit not with high load. Worked fine at that time, I will
>> search for the patch when I'm back home later today.
>>
> Here it is:
> http://lists.freebsd.org/pipermail/freebsd-geom/2008-December/003200.html
> The mail is quite old now, I don't know if the patch still applies.
> Will check that if I can find the time. I would be happy to see this
> committed after all this time :)

Yes, I was thinking about something like that. Patch mostly applies now
and even builds. May be I would just put there sx_sleep() instead if
msleep(), as topology_lock is sx.

Could somebody to review this and tell how correct is to not drop
topology lock between events handling and could there be places where
g_wait_event woken without holding topology_lock?

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C4F171C.9010106>