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>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1009031347490.3301@localhost6.localdomain6>
Date:	Fri, 3 Sep 2010 13:54:11 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Abhijeet Dharmapurikar <adharmap@...eaurora.org>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	arve@...roid.com, Rusty Russell <rusty@...tcorp.com.au>,
	linux-arm-kernel@...ts.infradead.org, linux-arm-msm@...r.kernel.org
Subject: Re: lazy disabling and idle states

Hi,

On Thu, 2 Sep 2010, Abhijeet Dharmapurikar wrote:

> I understand that lazy disabling was introduced so that we don't loose wakeup
> interrupts while going in to suspend. The way lazy disabling is implemented is

No, that's wrong. lazy irq disabling has nothing to do with suspend at
all. It's there to avoid expensive access to interrupt controller
hardware. In most cases when an interrupt is disabled via
disable_irq(), then the device does not issue an interrupt, so we
optimize that case and do the lazy disable. The suspend code just
utilizes this detail.

If a driver is shutdown completely and called free_irq() then the irq
line is disabled at the hardware level in any case.

> in disable_irq() the interrupt is marked as IRQ_DISABLED but the irq_chip's
> mask function is not called. As a result the interrupt remains enabled in the
> irq controller and is masked in the controller only when it is raised again.
> 
> This raises the question of unnecessary wakeups in idle power collapse case.
> By idle power collapse I mean the low power state where the processor is shut
> off during long idle periods. While in idle power collapse, the cpu could wake
> up from a disabled interrupt only to realize that it was marked IRQ_DISABLED
> (as a part of lazy disabling) and would call the mask function and go to idle
> power collapse again. This behavior could have negative effect on power
> consumption.
> 
> One solution that comes to mind is that the idle power collapse code, before
> going to sleep, could iterate over the irq_desc's of all the interrupts and
> call mask on the ones marked as IRQ_DISABLED to make sure that they are
> actually masked in the controller. This would fix the unnecessary wakeups from
> idle power collapse. But this operation is very lengthy and inefficient
> because it may end up calling mask on interrupts that have been already
> masked.
> 
> Are there other solutions to address this issue? Feel free to correct me if I
> missed a something and my conclusion is incorrect.

Fix the device drivers which keep a device in a state which will fire
interrupts after the driver called disable_irq(). 
 
Thanks,

	tglx
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ