[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <857be92d-1f7b-dee6-56cb-6138e07c2717@gmail.com>
Date: Fri, 8 Oct 2021 09:04:46 -0500
From: Ian Pilcher <arequipeno@...il.com>
To: Marek BehĂșn <kabel@...nel.org>
Cc: pavel@....cz, linux-leds@...r.kernel.org,
linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
hch@...radead.org
Subject: Re: [RESEND PATCH v5 2/2] leds: trigger: Add block device LED trigger
On 10/8/21 05:01, Marek BehĂșn wrote:
> On Wed, 6 Oct 2021 11:07:06 -0500
> Ian Pilcher <arequipeno@...il.com> wrote:
>
>> I have feeling that per-LED work items are likely to cause contention
>> for the mutex, since they will probably all have the same (default)
>> interval and they will usually be set up at about the same time (i.e.
>> at system boot). Instead, I would propose to have a single work item
>> that is simply scheduled for the next time work is "needed" and then
>> checks all LEDs that are due at that time.
>
> What about creating one work struct for all different interval values?
>
> That way if the user never changes the interval, there will be only one
> work struct.
>
> I wonder if this can be done in a sensible (i.e. not overcomplicated
> code) way.
I've been working on this (along with the other changes), and it's about
ready to go. I'll send it out later today, once I've had a chance to
write up the changelog.
Thanks!
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
Powered by blists - more mailing lists