From: Jay L. <jl...@en...> - 2005-09-29 19:48:15
|
Jay Lan wrote: > Andrew Morton wrote: >> Jay Lan <jl...@en...> wrote: >> >>>> >>>>> However, a connector is a >>>>> unreliable datagram socket. If we lose exit notification when system >>>>> is extremely busy, we lose accounting data once task struct is freed. >>>> >>>> >>>> That hasn't been demonstrated, has it? connector uses GFP_KERNEL >>>> and is in >>>> fact reliable. Stuff may get lost down in the bowels of netlink code, >>>> although connector does pass GFP_KERNEL into netlink. >>> >>> I ran my testing in March time frame. I used Evgeniy's fork generation >>> program (fork-test) to generate fork events. >>> The fork-test is like this: >>> # while 1 >>> # ./fork-test 10000000 >>> # sleep 1 >>> # end >>> >>> I used a user-space >>> program doing nothing but reading data and compares sequrence numbers. >>> >>> I ran the fork-test together with AIM7 and sometimes ubench. >>> >>> In earlier testings, i observed duplicate messages and a gap of >>> messages number (a chunk of messages got lost.) >>> >>> Later on, i have not seen duplicate messages, probably because >>> improvements made to netlink/connector. >> >> >> Yes, I don't think earlier versions of cbus/connector were wholly >> race-free. Testing would need to be redone on the in-kernel >> version. If >> netlink itself is not doing internal hard-coded-GFP_ATOMIC allocations I >> _think_ the whole thing should be reliable. >> >> If not, we need to work out where the messages went... > > Agreed. I will rerun my test later tis week. Guillaume, I could not find your fork connector patch in fork.c in 2.6.14-rc2 and 2.6.14-rc2-mm1? My test assumes your stuff being there... And my fclisten failed in bind... Something must have changed... I will sort it out. Thanks, - jay > > Thanks, > - jay > |