[Ksummit-discuss] [TECH TOPIC] giving freezer well-defined semantics
Jiri Kosina
jkosina at suse.com
Tue Jul 7 20:42:36 UTC 2015
Currently, the freezer has rather random semantics and there is no
rigorous definition that would provide clear guidance which kernel threads
should be freezable (and what rules they have to follow if they are).
The long and complicated history of freezer resulted in the current state,
where many kernel threads are marked freezable "just because", with
freezing points randomly sprinkled all over the place, and it really
complicates any efforts in cleaning up kthreads (which is why I am
interested in it -- we'd love to have kthreads cleaned up to make live
patching easier).
There are various possible aproaches to this. One is basically ad-hoc,
going over all the existing kthreads one by one, and fixing (probably just
removing, in most cases) its usage of freezer. The obivous disadvantage is
that this doesn't prevent anyone to abusing it again the same way in the
future.
Tejun came up with a different aproach at [1] -- basically getting rid of
the freezer completely, and rather annotating those I/O requests which are
needed for writing the hibernation image out, so that they make it through
all the affected subsystems, while other I/O requests would be frozen.
This would be rather dramatic change both in a way how kthreads work, how
hibernation works, and it'd be necessary to have means to mark I/O
requests as "needed for hibernation", therefore I think this would be a
good cross-subsystem topic.
[1] http://lkml.kernel.org/r/20150613232222.GB346@mtj.duckdns.org
--
Jiri Kosina
SUSE Labs
More information about the Ksummit-discuss
mailing list