[ACTIVITY] (Anton Vorontsov) 2012-04-23 - 2012-04-27

Anton Vorontsov anton.vorontsov at linaro.org
Mon Apr 30 10:57:17 UTC 2012


After a big move and other things, finally I can focus on the Linux
work. Now I have a high-speed internet in my new place, so using
'mumble' for conferencing is no problem any longer.

== Highlights ==

* We've got some 'looks fine' feedback on the userland LMK, and that's
  reassuring.
  The "bad news" is that there's not much of enthusiasm overall from
  Android folks. That's understandable as kernel LMK driver works and
  already in mainline^Wstaging kernel, so why bother. Well, it can't
  live in staging/ forever, so we'd better hurry up.
* ulmkd's Makefile is again suitable for GNU/Linux builds
  (as an addition to Android/Linux). This makes it easier for me
  to test, plus maybe there we'll be other users for the daemon.
* for_each_process and task->mm fixes finally merged into -mm.
  I will need a small documentation update for the series, but
  overall the series seem to be fine.
* Prepared a few fixes for the memcg slab accounting. The proposed
  slab accounting feature looks like exactly what was needed, except
  that it doesn't account slab for the root cgroup. If that's not
  a design decision, then it can be improved. If not, there are
  two ways: a) drop cgroups support and go solely w/ vmevent
  infrastructure b) try to push something like 'memory.available'
  attribute for memcg. 'a)' is easy, and 'b)' is probably what I'll
  try to implement tomorrow. Once implemented, we'll have all
  options ready, and so can mark cgroups as either fully suitable
  for lowmem notifications or not suitable by design.

== Plans ==

* I wonder if I need to make a deep-dive into Android build system
  and try to integrate ulmkd into Android image myself?
* Back to interactive governor improvements? Well, as far as I
  recall, the story behind interactive governor is very similar to
  LMK: nobody likes the cpufreq overall, and want generic power
  management improvements for the scheduler. At least, we need to
  get 'interactive vs. ondemand' cpufreq latency numbers. That
  would be a good starting point for any other improvements. And
  the problem with cpufreq latency measurements was that it takes
  ages for the benchmark to complete.

-- 
Anton Vorontsov
Email: cbouatmailru at gmail.com



More information about the linaro-kernel mailing list