[Ksummit-2012-discuss] [ATTEND] CPU hotplug, power management, newcomer's perspective to kernel development

[Srivatsa S. Bhat]

Hi,

I would love to participate in this year's Kernel Summit and contribute to
discussions related to CPU hotplug and power management (especially related
to suspend/resume scalability).

I have contributed bug-fixes and enhancements in the power management domain,
in areas such as Suspend/Resume and Hibernation, and also worked on enhancements
and fixes in some of the core infrastructure that they depend on, such as the
Freezer subsystem and CPU hotplug. These contributions have improved the
reliability and scalability of the suspend/resume framework. Currently I am
contributing towards improving the CPU Hotplug infrastructure and developing
a generic SMP booting framework to consolidate common code across various
architectures.

I would like to discuss about the wide-variety of uses that a concept like
CPU hotplug has (such as RAS, deep idle, Suspend/Resume, RT etc) and about
possibly restructuring its design and code to help such wide usecases to benefit
from the idea of such a CPU isolation framework. Taking that forward, I would
love to explore some of the possible performance improvements to Suspend/Resume
by designing a light-weight form of CPU hotplug - something that will
potentially take advantage of the fact that CPU hotplug in the suspend/resume
path is run when (almost) all tasks are frozen. Any such performance improvement
will give us twice the benefit per suspend/resume cycle, since CPU hotplug is
invoked during both suspend and resume.

Also, being relatively new to the kernel community, I would also be interested
in providing a newcomer's perspective to the kernel development process and
share some of the challenges that newcomers face, ranging from the initial
hurdles, to the challenge of progressively making bigger and better
contributions (of increasing value) to the kernel. And I would also like to
discuss about some of the steps that we can take to address these challenges
in order to encourage more developers to come on-board and contribute
effectively (for example, it would probably be a good idea to have a public
list of TODOs (of medium to long-term goals) for specific subsystems, so that
newcomers can attempt to take on those challenges and thus contribute to stuff
that actually helps in the long-run).

Regards,
Srivatsa S. Bhat