On Mon, Jun 17, 2024 at 8:57 PM Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote: > > On 2024-06-17 20:43:03+0000, Rafael J. Wysocki wrote: > > On Mon, Jun 17, 2024 at 8:37 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > On Thu, Jun 13, 2024 at 10:15 PM Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote: > > > > > > > > The ACPI _STR method returns an UTF-16 string that is converted to utf-8 > > > > before printing it in sysfs. > > > > Currently this conversion is performed every time the "description" > > > > sysfs attribute is read, which is not necessary. > > > > > > Why is it a problem, though? > > It's not a real problem, mostly it made the following changes simpler. > > > > How many devices have _STR and how much of the time is it used? > > > > > > Hint: On the system I'm sitting in front of, the answer is 0 and never. > > > > This was actually factually incorrect, sorry. > > > > The correct answer is 12 out of 247 and very rarely (if at all). > > Which doesn't really change the point IMO. > > > > > So Is it really worth adding an _STR string pointer to every struct acpi_device? > > The string pointer replaces a 'union acpi_object *str_obj', so no new > space is used. > Also in case the device _STR is present the new code uses less memory, as > it doesn't need the full union and stores utf-8 instead of utf-16. > (Plus a few more cycles for the preemptive conversion) > > In case no _STR is present both CPU and memory costs are identical. OK > Anyways, I don't really care about this and can also try to drop this > patch if you prefer. > Or drop the 'union acpi_device *' from the struct completely at your > preference. No, this is fine as is, thanks.
