On 10/12/2015 1:24 p.m., Alex Rousskov wrote: > On 12/09/2015 04:24 PM, Amos Jeffries wrote: >> On 10/12/2015 10:49 a.m., Alex Rousskov wrote: >>>>> Questions: Should we add a configuration directive to control whether >>>>> mlock(2) is called? If yes, should mlock(2) be called by default? >>>>> Should mlock(2) failures be fatal? > >>>> My answers are no, yes, yes. Since this is a startup thing squid.conf >>>> post-processing is probably too late. > > >>> Shared memory is not allocated until _after_ we parse squid.conf. > > >> Ah. Okay. > > > Does this understanding change your no/yes/yes answers? >
It makes them "maybe", no, yes. Though I am still not convinced exactly that squid.conf is the right place. As I said before: " In general if a setting is not something that can have a reasonable temporary default for a while, then be switched around in realtime. Then squid.conf is not a good place for it. I would make it mandatory on "-k check" (but not -k parse). Optional through a command line parameter on all other runs. (Remember we have long-args possible now so no need to squeeze it into a gap.) " Which is *not* doing mlock by default (retaining current behaviour). The slowdown then only happens on -k check, which is the manual test to check for problems. If mlock has a problem, a FATAL debugs (maybe exit too, but could keep going to find other errors) during the test run is very appropriate. The other (default / normal) runs having it OFF by default, since the -k check should have confirmed already that it is going to work. Unless the admin explicitly sets the config / command line option to ON. In which case complaints of slowdown are unjustified, and they can be told to disable again. > My plan was to tell them to disable mlock() (via a new squid.conf > directive) if all of the items below apply to them: > > (a) mlock() is successful now > (b) they are reasonably sure no environment or configuration changes > will make mlock() unsuccessful (if it is re-enabled) without them > knowing about the problem > (c) mlock() slows things down too much in their setup > (d) they want to trade faster startup for micro delays during runtime > Which seems to me all the things a -k check execution run will be testing for naturally. So if mlock errors are fatal on -k check, they get alerted to fix it before the running process is signalled to restart with the new config. Amos _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev