== Highlights == * Prepared some new features for vmevent: - a new low-memory blended attribute. This is used to wisely account page cache. The feature triggered a big discussion, so we might end up with something different as the discussion is still ongoing; - 'equal-to' attribute state (this is merged already); * Never-ending discussion on memcg and vmevents memory notifications continued; * ram_console feature seemed quite interesting, so I started looking more closely into it. Based on previous lkml discussions, it appears that the main obstacle is that we should use pstore. So, as a warm-up I started porting ramoops (which uses pstore in -next tree) driver to use persistent_ram. That would be a good reason to move persistent_ram out of staging/. * v3.4 is approaching rc7 (or final), so I had to dedicate some time for a pile of battery patches collected in my 'todo' mailbox.
== Plans == * Pekka asked to look into improving LT/GT/EQ handling in vmevent, make it table-based may be; * I was quite reluctant to getting my hands dirty into the cpufreq as nobody likes it, and thus I'm risking to get involved into another never-ending story, plus after refreshing Android git tree I noticed that Android guys are actively hacking it at this precise moment. So, to not step on each others' toes, I finally decided I'd better work on something else, thus I picked ram_console and friends.
On 05/07/2012 10:33 AM, Anton Vorontsov wrote:
- ram_console feature seemed quite interesting, so I started looking more closely into it. Based on previous lkml discussions, it appears that the main obstacle is that we should use pstore. So, as a warm-up I started porting ramoops (which uses pstore in -next tree) driver to use persistent_ram. That would be a good reason to move persistent_ram out of staging/.
From the discussions on the list, it it seemed we might want to use persistent_ram as a back end for pstore, instead of having ramoops use it directly. This allows drivers to target one interface (pstore) and have it multiplex the data back to the proper storage for the device.
thanks -john
On Mon, May 07, 2012 at 10:40:00AM -0700, John Stultz wrote:
On 05/07/2012 10:33 AM, Anton Vorontsov wrote:
- ram_console feature seemed quite interesting, so I started looking more closely into it. Based on previous lkml discussions, it appears that the main obstacle is that we should use pstore. So, as a warm-up I started porting ramoops (which uses pstore in -next tree) driver to use persistent_ram. That would be a good reason to move persistent_ram out of staging/.
From the discussions on the list, it it seemed we might want to use persistent_ram as a back end for pstore, instead of having ramoops use it directly. This allows drivers to target one interface (pstore) and have it multiplex the data back to the proper storage for the device.
I guess there's some misconception, probably because ramoops have recently switched to pstore (like 4 days ago ;-).
Pstore consists of three things: 1. An interface to store and retrieve messages (a backend iface); 2. A filesystem driver to represent retrieved messages; 3. Plus there is an ad-hoc oops dumper right inside the pstore.
Today ramoops is a ram storage facility for DMESG message type of pstore (badly named, as it stores only kernel dumps, not the whole dmesg as ram_console).
Ramoops is using pstore to receive messages, then it stores the messages (into RAM) and retrives them back [from RAM to pstore]. So ramoops is already a RAM backend for pstore, it just doesn't support ECC.
The plan is this:
1. make ramoops use persistent_ram library, basically this just adds an (optional) ECC support for ramoops. 2. add a new message type for pstore (KMSG, DMESG_ALL?) that denotes the whole kernel log; 3. make ram_console pass messages to the pstore instead of persistent_ram (with "DMESG_ALL" message type), then we can rename ram_console to pstore_kmsg or merge it into fs/pstore/platform.c, near the kmsg_dumper code; 4. rename ramoops.c to pstore_ram.c and persistent_ram.c to pstore_ram_core.c (or merge the two), as from now on it is just a RAM backend for pstore w/ ECC support.
linaro-kernel@lists.linaro.org
-
Anton Vorontsov -
John Stultz