[systemd-devel] Hardware watchdog support, slug speed.

[Lennart Poettering]

On Tue, 12.03.13 00:45, Sébastien Luttringer (seblu at seblu.net) wrote:

> > Humm the ioctl() is supposed to be cheap. And it is on all hw I have
> > tested it with. It appears that ob the hw in question it is not so
> > cheap, but that really sounds like a driver issue to me.
> 
> Before everything, ioctl is a syscall, and even if the hardware /
> driver is buggy, doing a syscall every loop turn (for nothing) is a
> performance cost which should be avoided.

No, this is the main event loop. It's executed only on events. It is not
performance relevant. 

> This is even more true on embedded devices where power is also
> important. You can do more than 10 ioctl each seconds (10 context
> swtich) in the pid 1.
> I don't thinks you can tell it's really cheap.

the main loop is not really a tight loop. It's something that runs on
some event, and not otherwise. There's little point in optimizing this
without having a clear knoweledge what the bootlenecks are.

> > Well, the ioctl issue above just indicates that the driver sucks, but
> > given how weakly the kernel iface is defined this is generally not a
> > reason not to continue to ping the hw.
> Why there is a variable to define in how seconds the watchdog is
> ping'ed if you don't honor it?

That variable declares how often to ping the hw *at least*. We optimize
power behaviour by always sleeping as long as we can, and not waking up
any earlier than strictly necessary. This also means we ping the hw when
we are woken up anyway, right before we go to sleep again, so that we
maximize our sleep time.

> Before blaming the driver/kernel developers, we can look into "our"
> interfaces and see why we don't respect it.

Blocking ioctls are unconditionally a stupid idea. There's no excuse for
that, and I am happy to tell that any kernel developer who wants to
listen...

> Why not just call the ioctl at RuntimeWatchdogSec? As everyone except.
> This let users choice how often they wants to call the hardware and
> even let them adapt to a buggy hardware with an higher value.

The loop is optimized to run as seldom as possible, not as often as
possible.

Also, just invoking the ioctl less often doesn't fix the issue too
much. A sleep of 500ms in the event loop is never OK. The only sane way
out of this is making this ioctl non-blocking in userspace, by invoking
it in a thread.

> - It's not free, it consume a lot of syscall by seconds in the main
> systemd event loop.

Yeah, but the lesson here is not to call it less often. It is instead of
making it non-blocking.

> - It doesn't honor the user configuration.

Hmm? It certainly does.

> - It doesn't respect the hardware minimum value (not only because
> there is no API).

Hmm? How would that matter?

> - It continue even if the initial configuration have failed, making
> things worst by trying to reopen /dev/watchdog each loop turn.

The enable ioctl is optional. It's the right thing to ignore it.

> - We are not able to use alternative watchdog device, when we have
> more than one (case on my laptop).

If this is necessary we can beef up the code to ping all available
watchdogs rather than just one.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.