linux-kernel - Re: PM regression in next

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:   Thu, 11 Jan 2018 16:45:37 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-omap@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: PM regression in next

On Thu, 11 Jan 2018 16:23:22 -0800 Tony Lindgren <tony@...mide.com> wrote:

> * Andrew Morton <akpm@...ux-foundation.org> [180112 00:18]:
> > On Thu, 11 Jan 2018 16:01:13 -0800 Tony Lindgren <tony@...mide.com> wrote:
> > 
> > > Hi all,
> > > 
> > > I'm seeing a considerable idle power consumption regression in
> > > Linux next, with power consumption for my idle test system going
> > > to 17.5mW compared to the usual 8mW on my test device.
> > > 
> > > Git bisect points to merge commit e130bc1d00a4 ("Merge branch
> > > 'akpm-current/current'") being the first bad commit.
> > > 
> > > I have also verified that commit 70286688e5ad ("ipc/mqueue.c:
> > > have RT tasks queue in by priority in wq_add()") is good, and
> > > commit e2d7fe89e8ae ("Merge remote-tracking branch
> > > 'init_task/init_task'") is good.
> > 
> > Do you mean that everything up to and including 70286688e5ad
> > ("ipc/mqueue.c: have RT tasks queue in by priority in wq_add()") is
> > good?
> 
> Yes I'm not seeing the regression in your branch at commit
> 70286688e5ad. I'm seeing it only with the merge commit
> e130bc1d00a4.
> 

That's weird.  All I'm seeing between 70286688e5ad and end-of-mm is:

tools-objtool-makefile-dont-assume-sync-checksh-is-executable.patch
ipc-mqueue-add-missing-error-code-in-init_mqueue_fs.patch

vfs-remove-might_sleep-from-clear_inode.patch

mm-remove-duplicate-includes.patch

mm-remove-unneeded-kallsyms-include.patch
hrtimer-remove-unneeded-kallsyms-include.patch
genirq-remove-unneeded-kallsyms-include.patch

mm-memblock-memblock_is_map-region_memory-can-be-boolean.patch
lib-lockref-__lockref_is_dead-can-be-boolean.patch
kernel-cpuset-current_cpuset_is_being_rebound-can-be-boolean.patch
kernel-resource-iomem_is_exclusive-can-be-boolean.patch
kernel-module-module_is_live-can-be-boolean.patch
kernel-mutex-mutex_is_locked-can-be-boolean.patch
crash_dump-is_kdump_kernel-can-be-boolean.patch

fix-const-confusion-in-certs-blacklist.patch
fix-read-buffer-overflow-in-delta-ipc.patch

kasan-rework-kconfig-settings.patch

sparc64-ng4-memset-32-bits-overflow.patch

lib-crc-ccitt-add-ccitt-false-crc16-variant.patch


And I don't see how any of those can cause this.  Did anything else
change, like context switch rates, interrupt rates, etc?