1 |
On Mon, 20 Aug 2012 12:04:26 +0900, heroxbd@×××××.com wrote: |
2 |
> Rich Freeman <rich0@g.o> writes: |
3 |
> |
4 |
>> On Fri, Aug 17, 2012 at 3:29 AM, Luca Barbato <lu_zero@g.o> |
5 |
>> wrote: |
6 |
>>> It can be not so tiny, surely busybox+openrc gives a better gain in |
7 |
>>> many |
8 |
>>> cases. |
9 |
>>> |
10 |
>> |
11 |
>> I suspect that it will depend greatly on what services you're |
12 |
>> running, |
13 |
>> and what order they happen to start in, and what you care about. In |
14 |
>> theory slamming the kernel with a ton of processes will allow it to |
15 |
>> manage its queues better with a fuller understanding of demand. |
16 |
>> systemd can potentially short-cut this a bit further since it can |
17 |
>> consider a dependency resolved if nothing more than a socket is |
18 |
>> created, which is a clever trick (I have no idea how well it works |
19 |
>> out |
20 |
>> in practice, though I have used a .socket service once and that |
21 |
>> worked |
22 |
>> out fine (with the caveat that the first connection fails)). |
23 |
> |
24 |
> Yeah, this is a brilliant idea. |
25 |
|
26 |
just as a side note, when I was doing performance latency testing (for |
27 |
industrial robotics applications) on real-time Linux kernels (RTAI, soft |
28 |
real-time preempt, and hard real-time preempt) I noticed that I got |
29 |
better latencies when when I loaded up the system with a LOT of |
30 |
processes and workload. If you end up looking into the RT stuff, let me |
31 |
know off list and maybe I can send a link or six. |
32 |
|
33 |
EBo -- |