On 07/16/2013 03:26 AM, Lennart Poettering wrote: > On Mon, 08.07.13 18:39, Karol Lewandowski ([email protected]) wrote:
>> According to my analysis /proc access is costly and it would >> be best to cache the result for later use. Difficulty comes >> from trying to keep cache up to date, though. > > We can't really cache this. This stuff is already racy, as by the time > we read the attributes the process might already be gone. Agreed, this is why I have been naively thinking that caching wouldn't be that bad... However, sending all the required information in message itself is clearly the best solution to this problem. > I think the best way to deal with the performance issue here is the > stuff discussed here: > > https://bugzilla.redhat.com/show_bug.cgi?id=963620 > > i.e. just have the kernel augment our messages with the data we need, > unconditionally. That way we fix both the race issue, and the > performance issue, since the data is just there and we can make use of > it without any further work. Thanks a lot for this link! Having this issue sorted out will allow me to take closer look into "eliminating" 64-bit divisions in message receive path. ARM doesn't support divide operation so every div[1] is being done purely in software. [1] Every div/% by non-constant value and every div/% by 64-bit constant results in call to (slow) __aeabi_div*. Thanks _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
