[systemd-devel] High CPU usage of journald

Lennart Poettering lennart at poettering.net
Tue Feb 19 17:46:35 PST 2013

On Tue, 19.02.13 19:21, Holger Hans Peter Freyther (holger at freyther.de) wrote:

> > Does this mean I will now optimize them all away for you? No, not
> > really, I don't even have the appropriate hardware to profile this. Does
> > this mean I will merge good patches that optimize this? Hell, yes!
> It works both ways. If I'm going to spend a significant amount of my time
> to make journald usable on embedded hardware (right now my product doesn't
> really need it) I want to have some kind of commitment that while I cut back
> on dynamic allocations not a ton of new ones get introduced at the
> same time.

Well, I am not going to give you a blanket promise that I will merge any
patch you send us, but yes, we will consider every patch and merge the
good stuff, and we will try to avoid making things worse again. I mean,
the code in question otherwise is not really code to refactor anyway in
my eyes, so I think there's not much risk to fuck this up again

Also, adding a comment to dispatch_message_real() saying:

      /* Hey, this code is run for each log line, consider it an inner
         loop function, so minimize memory allocations and sprintf()
         invocations please, thxgoodbye! */

should make sure enough that people changing the code keep in mind that
the call is performance-sensitive.

> Just to be clear, when I talk about cutting back dynamic allocations I don't
> mean introducing char foo[SHOULD_BE_BIG_ENOUGH_BUT_IS_NOT] but to be a bit
> more clever about the usage. E.g. have a 'scratch' string, avoid reallocs
> in steps of one, etc.

Wel, keep it readable, that's most important...

> PS: I thought Nokia hooked you up with a N900 or such?

Yeah, and I sold it on ebay a while ago... ;-)


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list