On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote: > On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote: > > On Monday 05 March 2007 08:23, Yar Tikhiy wrote: > > = > How will it break them? swap backing only touches swap if there is > > = > memory pressure, i.e. precisely the situation in which malloc backing > > = > will panic. > > = > > = I forgot that in BSD swap wouldn't be allocated in advance to its > > = consumers. Then removing the -M flag and making swap backing the > > = default is a very sound choice. Thank you for correcting me. > > > > Yar, would you change the man-page's advice and the default, then? > > Yes, I'll be glad to if no objections arise until I finish updating > my CURRENT machine, i.e., tomorrow. :-) > > > Someone still needs to look into the panic... Who would that be? > > Obviously, Mr(s). Someone. :-) > > The md case exposes a quite tangled nature of the problem. Funnily > enough, kernel malloc() cannot just fail in the case because it > must not fail if called with M_WAITOK. This means that the system > has quite a rough choice: > > - put the requesting thread to sleep forever; > - grow kmem_map, eventually sacrifice all RAM to the greedy thread > and die sooner or later; > - panic immediately. > > If all malloc() callers in the kernel were ready to deal with > allocation failure, the system could just tell the greedy thread > to buzz off. But too many kernel parts depend on malloc(M_WAITOK) > never failing. Perhaps it's the root of the problem.
Mark callers that are ready for M_WAITOK failure with some additional flag, like M_FAILOK (feel free to propose meaningful name there). At least malloc()-based md could then use it.
pgp7l3bai5KMT.pgp
Description: PGP signature
