Profile cover photo
Profile photo
Lennart Poettering
11,101 followers -
A Saturated Grey
A Saturated Grey

11,101 followers
About
Posts

Post has attachment
So, I caved in. Since G+ is dead since a long time, and everybody kinda moved on towards greener pastures I also have a Twitter account now, where I do hope to post some technical bits now and then.
Add a comment...

Post has attachment
I am a bit late to the party (been hiking to Choquequirao), but this talk from a BSD guy is actually pretty excellent. A view from the BSD people on systemd, and a pretty positive one at that (don't let yourself be misled by the title). Recommended.
Add a comment...

Post has attachment

Post has attachment
One more week and the AllSystemsGo! CfP closes. Make sure to submit your talk proposals now, to present at everbody's favourite low-level Linux userspace conference!
Add a comment...

Post has shared content
Add a comment...

Post has attachment
Add a comment...

Post has attachment
Don't forget, the All Systems Go! 2018 CfP is open now! (And no, it's still not a golang conference but one about low-level Linux userspace components).

Make sure to submit your talk soon, and see you all in Berlin!
Add a comment...

Post has attachment
Hey, Google+, I just finished writing these docs about cgroupsv1+cgroupsv2+delegation+systemd. If you hack on low-level container stuff you might want to have a look.

To make this more fun to read, it even has emojis!
Add a comment...

Hmm, so let's say you wanted to query the system you are running on for some very basic values: how many tasks are currently running in parallel on my system? and: how many tasks can run on my system in parallel?

With two conditions:

1. A "task" in this context shall be understood as kernel schedulable entity, i.e. I want the total number of threads of all processes.
2. I don't want to iterate through the processes and threads in O(n) fashion. I want it in O(1) or something like it.

So, how would you do this on Linux? — This sounds like such a trivial thing to do, but I am too dumb to find a way:

1. There appears to be no interface in /proc or elsewhere that exposes the number of current tasks at all. All you can do is count the /proc/$PID/task/$TID dirs. Yuck!
2. There are two interfaces in /proc for setting the limit of tasks: /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max. They are set to different things, but uh, wat, what's the supposed difference? Which one is the one that I want to use? (oh, and why in heaven "_" vs. "-"?)
3. The "pids" cgroup controller in theory would expose the right information, except for one limitation: it does so only on non-root cgroups. For the root cgroup it neither supports limits nor exposes the current counters.

So, lazyplus, what's the proper API I should use? What am I missing?

(Or, if nobody knows: what a sad little OS we are all hacking on!)
Add a comment...

Post has attachment
Uh, so Phoronix is being Phoronix, and reports quite misleading news. Let me quickly put a few things straight: first of all, "one million lines of code" is really misleading, as that appears to be raw lines of files managed by git. Since we carry large amount of documentation the actual lines of code are much lower. Using a tool like "sloccount" for counting lines of code reveals systemd currently carries ~342K lines of code, of which ~318K are proper C code. Which isn't actually that much. To put things into perspective, as one example wpa_supplicant alone has ~451K lines of code, of which ~351K are proper C code. I think as long as the supposedly huge systemd tree with all its components, such as resolved, networkd, timesyncd, nspawn, journald, and so on only reaches 75% of the size of the codebase of you frickin wifi subsystem, I think we are good, aren't we?

I mean, sure, apples, oranges and stuff, but still…

(and yeah, even stuff such as supposedly "lean" projects such as uclibc weigh 329K lines of code already…)
Add a comment...
Wait while more posts are being loaded