[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF2d9jhng-A=sYzhy=KX0xMVFDj+jF9W7mkkZYyaLncvgv=ZTQ@mail.gmail.com>
Date: Sat, 21 Mar 2015 19:04:16 -0700
From: Mahesh Bandewar <maheshb@...gle.com>
To: David Miller <davem@...emloft.net>
Cc: j.vosburgh@...il.com, andy@...yhouse.net, vfalico@...il.com,
nikolay@...hat.com,
Maciej Żenczykowski <maze@...gle.com>,
linux-netdev <netdev@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next v2 0/4] bonding work-queues, try_rtnl() & notifications
On Sat, Mar 21, 2015 at 3:17 PM, David Miller <davem@...emloft.net> wrote:
>
> From: Mahesh Bandewar <maheshb@...gle.com>
> Date: Fri, 20 Mar 2015 22:39:15 -0700
>
> > This patch series tries to address the issue discovered in various work-
> > queues and the way these handlers deal with the RTNL. Especially for
> > notification handling. If RTNL can not be acquired, these handlers ignore
> > sending notifications and just re-arm the timer. This could be very
> > problematic if the re-arm timer has larger value (e.g. in minutes).
>
> I already made it very clear how I want this kind of problem solved.
>
> Make the person holding the RTNL semaphore do the notification work
> for you.
>
> All of this deferral stuff is error prone and sloppy.
I think you missed my earlier reply to your message. In summary, the
notification deferral is 1ms which should not cause any trashing; more
over with that suggested approach the rtnl-owner will have to do your
job and will be subjected to the latencies which may be undesirable.
OTOH this patch series is not adding any new deferral work, but just
making it bug-free.
Thanks,
--mahesh..
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists