Re: INTR_MPSAFE to network device drivers
Kyunghwan Kim writes: > On Wed, Dec 18, 2002 at 04:53:00AM +0900, Kyunghwan Kim wrote: > > On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: > > > > mbuf and bpf routines are all mp-safe, so it seems that > > > > it is safe to make network device drivers out of Giant lock. > > > > Or is there any unresolved related issues? > > > > > > Yes, the mbuf allocator must occasionally call kmem_malloc(), which > > > requires Giant.This means no net driver can be made INTR_MPSAFE, > > > or it will eventually panic when kmem_malloc is called. > > > > I found and read the thread that you and Alan had discussed about this > > problem just before. Then what about making updated version of mb_pop_cont() > > that accepts occasionally acquiring Giant? > > Oh, sorry. Conclusion of the thread was preallocation. > But it doesn't seem that preallocation is the correct way. Well, the "right" way is bringing kmem_malloc() out from under Giant. Preallocation would just be an interim measure until kmem_malloc() was mp-safe. The VM maintainers were only recently made aware of this issue. I have no idea what the scope of the changes to make kmem_malloc() mpsafe would be, so I have no idea when kmem_malloc() will become mpsafe. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INTR_MPSAFE to network device drivers
On Wed, Dec 18, 2002 at 04:53:00AM +0900, Kyunghwan Kim wrote: > On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: > > > mbuf and bpf routines are all mp-safe, so it seems that > > > it is safe to make network device drivers out of Giant lock. > > > Or is there any unresolved related issues? > > > > Yes, the mbuf allocator must occasionally call kmem_malloc(), which > > requires Giant.This means no net driver can be made INTR_MPSAFE, > > or it will eventually panic when kmem_malloc is called. > > I found and read the thread that you and Alan had discussed about this > problem just before. Then what about making updated version of mb_pop_cont() > that accepts occasionally acquiring Giant? Oh, sorry. Conclusion of the thread was preallocation. But it doesn't seem that preallocation is the correct way. -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INTR_MPSAFE to network device drivers
On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: > > mbuf and bpf routines are all mp-safe, so it seems that > > it is safe to make network device drivers out of Giant lock. > > Or is there any unresolved related issues? > > Yes, the mbuf allocator must occasionally call kmem_malloc(), which > requires Giant.This means no net driver can be made INTR_MPSAFE, > or it will eventually panic when kmem_malloc is called. I found and read the thread that you and Alan had discussed about this problem just before. Then what about making updated version of mb_pop_cont() that accepts occasionally acquiring Giant? -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INTR_MPSAFE to network device drivers
Kyunghwan Kim writes: > Is it okay to add INTR_MPSAFE for all INTR_TYPE_NET drivers? NO! > mbuf and bpf routines are all mp-safe, so it seems that > it is safe to make network device drivers out of Giant lock. > Or is there any unresolved related issues? Yes, the mbuf allocator must occasionally call kmem_malloc(), which requires Giant.This means no net driver can be made INTR_MPSAFE, or it will eventually panic when kmem_malloc is called. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
INTR_MPSAFE to network device drivers
Is it okay to add INTR_MPSAFE for all INTR_TYPE_NET drivers? mbuf and bpf routines are all mp-safe, so it seems that it is safe to make network device drivers out of Giant lock. Or is there any unresolved related issues? -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
