Re: CVS commit: src/distrib/sets/lists/tests
"Antti Kantee" writes: > Module Name: src > Committed By: pooka > Date: Fri Nov 5 11:32:43 UTC 2010 > > Modified Files: > src/distrib/sets/lists/tests: mi > > Log Message: > +tp Can we document what "+tp" means? -- HE CE3OH...
Re: CVS commit: src/sys
Christoph Egger wrote: > > Module Name:src > > Committed By: rmind > > Date: Fri Nov 5 01:35:58 UTC 2010 > > > > Modified Files: > > src/sys/dist/pf/net: if_pfsync.c pf_norm.c > > src/sys/netinet: in_var.h ip_id.c ip_input.c > > > > Log Message: > > ip_randomid: make mechanism MP-safe and more modular. > > > > OK matt@ > > Where is ip_id_fini() called? If we don't we leak > kernel memory. We do not. I have added it as a destructor. We may #if 0 it. -- Mindaugas
Re: CVS commit: src/sys/kern
> > In M_WAIT case, m_reclaim() will run and run until get mbuf cluster > > if mclpool limit reached. If m_reclaim() repeatedly but cannot to > > get new mbuf cluster, m_clget() will not return. > > > > network stacks using mbufs is use with M_DONTWAIT, but it will failed > > to get new mbuf cluster in this case. "freeze" means that. > > Yes, hitting the limit would trigger m_reclaim() and m_clget() would > block. It is a quite similar condition to memory or KVA starvation. > However, why such blocking in sosend() is problematic, or, how is it > different from any other WAITOK allocation? > > I see the point about the limit. Inadequately low limit may cause many > blocking processes, while there is still a lot of memory. However, in > such case, perhaps you want PR_LIMITFAIL, instead of PR_NOWAIT? Note > that PR_NOWAIT (M_DONTWAIT) has other implications, e.g. it might fail > due to try-locks. So, I think your fix is incorrect. Can this be fixed, please? Thanks. -- Mindaugas
Re: CVS commit: src
> Added Files: > src/share/man/man4: fujitsu.4 > src/sys/dev/acpi: fujitsu_acpi.c > > Log Message: > Merge ACPI Fujitsu Driver. Too bad device name as sony(4). Won't we have other Fujitsu devices? --- Izumi Tsutsui
