[systemd-devel] [PATCH 0/2] RFC for avoid dynamic allocation in?journald

Lennart Poettering lennart at poettering.net
Wed Apr 17 11:13:36 PDT 2013


On Mon, 08.04.13 19:53, Holger Hans Peter Freyther (holger at freyther.de) wrote:

> 
> On Mon, Apr 08, 2013 at 07:06:44PM +0200, Lennart Poettering wrote:
> 
> > > Is it really needed to determine the cgroup of /proc/1 on every message?
> > > Couldn't journald keep the variables for its identity around?
> 
> > a) use gcc's __thread support, i.e. have one static cache var per
> >    thread. Since all stuff in systemd's repo is essentially single
> >    threaded this should give you the desired effect and should be a
> >    pretty simple way to have caches without having to think about
> >    concurrency. Of course, this only really works for small fixed-size
> >    data that needs no destructors (i.e. no free()).
>  
> > b) Only provide the caching in the main thread, and be un-cached
> >    expensive in all others. This is slightly less nice, but effectively
> >    gives you the same properties for systemd's own code. We have a call
> >    in util.c to detect if we are running in the main thread:
> >    is_main_thread().
> 
> I understand the constraints. My hardware (like most older ARM cores)
> doesn't have a dedicated HW register for TLS. So I would like to avoid
> any usage of threading. What is the argument against caching it inside
> the application layer? E.g. is it fair to assume that journald will be
> launched once systemd has created the cgroup?

Well, certainly, we can always cache things in the Server structure. In
fact we should certainly cache the machine ID and boot ID string there,
instea dof regenerating it all the time.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list