On Dec 20, 12:51 pm, Mohit Chawla <mohit.chawla.bin...@gmail.com> wrote: > On Mon, Dec 20, 2010 at 11:47 PM, Robin Bowes > <robin-li...@robinbowes.com>wrote: > > > I updated his modification to use facter to get the no. of available > > cores, and to display the core used when each instance starts > > Using facter seems clean enough, but I was wondering if getting the > information from cpuinfo instead would make it, so to say, foolproof.
Is the task scheduler for some reason unable to move puppetmasterd tasks between CPUs if this is not done? In other words, is there even a problem here to be solved? The patch appears to constrain each puppetmasterd to be scheduled only on a specific core, which in many cases could be more of a problem than a solution. For instance, if one core is loaded down with a heavy computation, then the scheduler would be unable to migrate that core's puppetmaster tasks to a different one. Only if the scheduler is already unable to do that does it make sense to me to accept this patch. If the general concept is adopted then I, too, have reservations about running Facter from the initscript. The scope of the script is narrow enough that I think it would be more appropriate to retrieve the information more directly, i.e. from /proc/cpuinfo. Also, it would assuage my sense of efficiency to move the determination of the number of cores outside the loop. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
