[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAFj5m9KDFNi+8AMdGeJzgbsKFnfanWJk2dESeCgdF=KXi+9arA@mail.gmail.com>
Date: Mon, 10 Nov 2025 17:44:55 +0800
From: Ming Lei <ming.lei@...hat.com>
To: Enzo Matsumiya <ematsumiya@...e.de>
Cc: Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>, linux-nvme@...ts.infradead.org,
Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...com>, Sagi Grimberg <sagi@...mberg.me>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nvme-pci: trigger disk activity LED
On Tue, Mar 1, 2022 at 11:30 AM Enzo Matsumiya <ematsumiya@...e.de> wrote:
>
> On 02/28, Jens Axboe wrote:
> >On 2/28/22 2:22 AM, Christoph Hellwig wrote:
> >> I don't think we should add code to the absolutel fast path for
> >> blinkenlights.
> >
> >Agree. It'd be a lot better to put the cost on the led trigger
> >side, and not need anything in the fast path for block devices.
> >Monitor disk stats, or something like that.
>
> There's been at least 4 attempts to do so, as far as I'm aware (one of
> them being mine). All got rejected due to the complexity it introduced,
> that's how I ended up with this one-liner.
>
> Performance-wise, I'm understand the problems, but according to ftrace,
> ledtrig_disk_activity() adds an average of 0.2us overhead, whether an
> LED is assigned or not. Is that really unacceptable?
>
> If so, would introducing a CONFIG_NVME_LED (default =n) and wrap that
> call around it make it better? Then at least there's a chance to inform
> users that desires this feature about performance costs.
Another solution is to do it in userspace by tracking iostat in a fixed period,
such as, triggering one led activity if any read/write IO happens during 0.5sec.
Thanks,
Powered by blists - more mailing lists