> > Yes - because if you think about it that tells you that nobody is hitting > > it with the old code and it probably doesn't matter. > > I don't understand this reply. It's a matter of priorities. There are hundreds of potential security holes turned up by scanners, 2,500+ filed bugs in kernel bugzilla alone. Which matters more - fixing the bugs people hit or the ones that they don't and which have a very high cost impact on other users ? > Likewise, I'm pointing that byte-sized circular buffers will also be > corrupted under certain circumstances (when the head comes near the tail). Yes. I believe the classic wording is "this problem has not been observed in the field" > 2. I'm not sure where you arrived at the conclusion that set_bit() et.al. is > fast on x86. Besides the heavy-duty instructions (lgdt, mov cr0, etc), the > bus-locked bit instructions are among the most expensive instructions in the > kernel. > I've attached a smoke test I use for lightweight validation of pty slave reads. > If you run this smoke test under perf, almost every high-value hit is a > bus-locked bit instruction. Check out canon_copy_from_read_buf() which performs > the actual copy of data from the line discipline input buffer to the __user > buffer; the clear_bit() is the performance hit. Check out cpu_idle_loop()... And then go and instrument whether its the bit instructions or the cache misses ? If there is a significant performance improvement by spacing the fields carefully, and you don't have other ordering problems as a result (remembering that the compiler has a lot of re-ordering options provided the re-ordering cannot be observed) If that's the case then fine - submit a patch with numbers and the fields spaced and quote the performance data. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
