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] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Jan 2024 14:46:46 +0000
From: Jack Allister <jalliste@...zon.com>
To: <dave.hansen@...el.com>
CC: <bp@...en8.de>, <dave.hansen@...ux.intel.com>, <hdegoede@...hat.com>,
	<hpa@...or.com>, <jalliste@...zon.com>, <juew@...zon.com>,
	<len.brown@...el.com>, <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
	<pdurrant@...zon.com>, <peterz@...radead.org>, <rafael.j.wysocki@...el.com>,
	<rafael@...nel.org>, <tglx@...utronix.de>, <usama.arif@...edance.com>,
	<x86@...nel.org>
Subject: Re: [PATCH v4] x86: intel_epb: Add earlyparam option to keep bias at performance

> Jack, I'd really appreciate if you could please slow down.

I'm sorry about this, I'm still extremely unfamiliar with the open-sourcing conventions/
workflow when working with mailing lists & the upstreaming to the Linux kernel. I have
taken this feedback & have started to look through the maintainer tips & docs for
guidance.

Also sorry for the delay in actual response here too, general work responsibilities & the
holiday period has had an affect here.

Before I go ahead with posting up a revision 5 with all of your queries/suggestions I do
have a few questions I'd just like to clarify.

> We could, for instance just support this pair:
>	intel_epb=auto		(default, will hack performance=>normal)
>	intel_epb=preserve	(leave it alone)

With the suggestion above you mentioned implementing this, if this was to be implemented
do you think keeping it `intel_epb_restore_default` as a bool is still worth it? e.g:

```
static __init int intel_epb_no_override_setup(char *str)
{
	if (!str)
		return 0;

	if (!strcmp(str, "preserve"))
		intel_epb_no_override = true;
```

Or do you think it would be worth actually removing `intel_epb_no_override` and creating
a module variable `intel_epb_restore_default` which is an enum of the performance values.

Doing so would then allow for expansability in the future which you had already alluded to
e.g setting to other values such as EPB_INDEX_BALANCE_POWERSAVE/PERFORMANCE.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ