2009/9/20 Lorenzo Villani <lvillani@xxxxxxxxxxxxxxx>: > On 09/20/2009 06:28 PM, Steve Grubb wrote: >> >> Not at all. These days the only need for xinetd is in memory constrained >> systems. For mainline x86_64 bought with typically 4Gb of main memory, >> xinetd >> is a thing of the past. That's my point. >> > Well, I am probably part of that 0.000001% who would like some services to > start on-demand. > For example I don't print all the time and I prefer to have cups start only > when needed, then die instead of having it waiting for no real purpose. Now, > this is a case in which it doesn't make sense (you start xinetd instead of > cups for no real gain) but it can be useful with some setups. > > Even if I have a quad-core system with 4Gb of memory available I always > prefer to find a better use for it. Let's be theoretical here for a second. In our von neumann machine architecture, a process needs to be initialized, where the code and data are read off the slow storage into the fast storage, the code path is executed, and the run time state is set up. In order to use the service, this process always has to happen. While the process, a certain amount of memory has to be used. These are fundamental issues that apply to how we use von neumann machines. You're discussing the process of managing the lifecycle of this core process. When loading cups on startup, as a standalone process, this process is done once, and then the results are stored in the memory. When the system runs out of memory, the state of the program is pushed back to the slow storage in the form of swap. Assuming the process is swapped out between every run, you incur the expensive cost of reloading the state from the hard drive. You don't incur the cost of reinitializing the state, although there might be some relatively minor overhead (OS handling swapping of processes, the process updating it's state in case something else on the system has changed since the process was paused). In the best case scenario, this never occurs, but then a few precious megabytes of your 4GB (everyone should be so lucky) are taken up. If you have 4GB, not swapping and keeping the process in runtime memory will give you the most responsiveness. If you're an end user, this is probably what you want. If you have less, you have to make a decision. Do we load it on start and swap it out, or do we manage it on demand. You're basically asking this question. Given the costs, you're really asking the wrong question as an end user. It really doesn't matter at all. To the end user, you're offering the user too much choice, where the end user is not educated enough to know the difference, doesn't care, and just wants printing to work. Of course, there are a number of other benefits to using inetd or xinetd pointed out in this thread. Assuming your services are KISS compliant, meaning they're lightweight, doing everything on demand is The Right Thing (tm). (Proving this is left as an exercise to the reader.) -Yaakov -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
