Ok, thank you all. I will do what you suggested: add a "clear" flag in my stats, which will be tested (and cleared) by each per-cpu thread. That seems fine, and without the need to lock. But, however, as I am a kernel newbie, I've still have my doubts about locking and caching issues. It's so abstract that I cannot understand it completely. Here they are my questions: * I asked what would happen if I am resetting a counter (actually the whole struct with memset) in one CPU while the other one is updating it. What would be the worst thing it could happen? For example, if the counter is of type long (64 bytes), could it happen that one CPU updates upper 32 bytes while the other CPU clears lower 32 bytes, thus corrupting the counter's value? Here's Henrik's answer in the previous email: > >counters, not anything strange or difficult (I guess that even if some > >other cpu would be incrementing one counter, instead of resetting to >> cero, its value would be one, or something similar). >No, without locking or serialization by doing the reset from the >per-cpu thread the reset can be lost. Why would be lost? In any case, the result would be strange, no? * Keith talked about cache bouncing. This is what I want to avoid, and the reason for which I use per-cpu variables. The process of packets should be kept as much parallel as possible. But cache issues are very abstract (you don't "see" them when programming, they happen in hardware level) and I didnt find any good reference to learn about this. Is there any book, article or whatever, and if it's possible, oriented to Linux kernel programmers? Thank you again for making programming in Linux a bit easier. Regards Aritz Bastida - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
