lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ