Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 8 Oct 2021 12:01:16 +0200
From:   Marek =?UTF-8?B?QmVow7pu?= <kabel@kernel.org>
To:     Ian Pilcher <arequipeno@gmail.com>
Cc:     pavel@ucw.cz, linux-leds@vger.kernel.org,
        linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
        hch@infradead.org
Subject: Re: [RESEND PATCH v5 2/2] leds: trigger: Add block device LED
 trigger
Message-ID: <20211008120116.65aec469@thinkpad>
In-Reply-To: <749c46a3-5d02-08ef-2a45-e785d65999c7@gmail.com>
References: <20211004155546.1120869-1-arequipeno@gmail.com>
        <20211004155546.1120869-3-arequipeno@gmail.com>
        <20211005232738.371df6b8@thinkpad>
        <749c46a3-5d02-08ef-2a45-e785d65999c7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 6 Oct 2021 11:07:06 -0500
Ian Pilcher <arequipeno@gmail.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.

Marek