[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210528133347.46634db7@coco.lan>
Date: Fri, 28 May 2021 13:33:47 +0200
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: Marek BehĂșn <kabel@...nel.org>,
linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
linuxarm@...wei.com, mauro.chehab@...wei.com,
gregkh@...uxfoundation.org
Subject: Re: [PATCH v2 16/17] leds: leds-nuc: add support for changing the
ethernet type indicator
Em Wed, 26 May 2021 16:51:12 +0200
Pavel Machek <pavel@....cz> escreveu:
> Hi!
>
> > > You say that for this controller it would be bad to do in SW, because it
> > > would take too much time in BIOS calls. (I wonder how much...)
> >
> > Yeah, it would be interesting to know how much. However, measuring BIOS
> > latency and time spent on such calls can be tricky: one needs to use a
> > high-res clock that it is not used anywhere else, in order to measure
> > it.
>
> I'm sure you can time kernel compilation while LEDs are using software
> netdev trigger, for example.
I can't see how. I mean, the problem is to monitor the impact of the
BIOS call with may affect not only the application using the LED, but
all other applications running at the same time on different CPUs,
as the BIOS may want/need to lock other CPUs while its code is running, as
it can't see the Linux CPU locks.
Thanks,
Mauro
Powered by blists - more mailing lists