linux-kernel - Re: [PATCH v2] cpuidle: Fix the menu governor to boost IO performance

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 4 Nov 2009 10:39:13 +0100
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, lenb@...nel.org,
	mingo@...e.hu, yanmin_zhang@...ux.intel.com, jens.axboe@...cle.com,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Subject: Re: [PATCH v2] cpuidle: Fix the menu governor to boost IO performance

Hi Arjan,
On Tue, Sep 15, 2009 at 4:42 AM, Arjan van de Ven <arjan@...radead.org> wrote:
> From: Arjan van de Ven <arjan@...ux.intel.com>
> Subject: cpuidle: Fix the menu governor to boost IO performance
>
> Fix the menu idle governor which balances power savings, energy efficiency
> and performance impact.

I've tested this patch on an Atom based netbook with SSD, and I see
10% improvement in latencies for reading a single 4k block from disk.

During this test, while looking at powertop, I found that my CPU was
sitting in polling mode for milliseconds (percentage was however
negligible).
I never recalled seeing a non-zero time spent polling, so I looked at
the patch and found:
> +       /*
> +        * We want to default to C1 (hlt), not to busy polling
> +        * unless the timer is happening really really soon.
> +        */
> +       if (data->expected_us > 5)
> +               data->last_state_idx = CPUIDLE_DRIVER_STATE_START;
Commenting the if, (the previous behaviour), I no longer see the
polling, while I still get the performance improvement.

I wonder if that '5' is a bit too much. According to my BIOS ACPI
table, the Atom latency for C1 is ~ 1us, so there is very little
payback in polling on such processors. Should the check use the ACPI
declared C1 latency to decide whether we should poll or go to C1?

An other consideration is that sometimes, even if we expect to idle
for a short time, we end up idling for more (otherwise I would never
have seen ms polling, when expecting at most 5us). Should we set up a
timer, that would fire when switching to an higher C state would
conserve more energy?

Thanks,
Corrado
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/