On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > ?? 2012??1??30?? ????2:36??Kostik Belousov <kostikbel_at_gmail.com> ?????? > > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote: > >> I have two boxes, one is AMD Athlon 610e 2.4G with FreeBSD-current > >> patched with pcid.2.patch? It works well without other issue and it > >> seem the pcid patch > >> does not affect other part of the kernel. The other one is Sandy > > Athlons do not have PCID and probably will never implement it. They use > > other tricks to get similar optimizations, transparently to the OS. > > > Just curious, is this AMD similar optimizations > Address Space Number (ASN) and Global flag > US Patent 6,604,187. > http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html This and the same-important next item 'The TLB Flush Filter' is what I referred to. > I did not found anything about ASN in the AMD manual It is a transparent optimization, which does not require any OS support. Intel PCID is completely different, it shall be explicitely handled by OS. It is some consequence of the nested pages support, AFAIU. > > >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the > >> pcid.2.patch seems > >> dependent on AVX and XSAVE stuffs which is available on -current). But > >> it hangs up just in a few minutes. I doubt the nvidia-driver which is > >> not recompiled with > >> patched kernel is the root, I will check this out later, but does > >> anyone meet similar problem? > > There are two many variations compared to the config I did tested. > > I do not see anything obvious in the changes between HEAD and stable/9 > > which could be blamed. Nvidia driver might be bigger suspect, but again, > > I am not aware of anything wrong with it. > > > >> > >> I have two question about the pcid.2.patch > > > > Item 2 is clean, I fixed it. > > > > For the item 1, I was only able to decipher the proposal to optimize > > the global shootdown handler to restore the %cr3 with bit 64 set to not > > invalidate current PCID. Is there some more changes ? > > > yes, that is what I meant. I was wondering using another way that each > process has different > pcid in each active processor, just as the freebsd mips and powerpc > uses. But obviously this way > is more friendly to non-pcid x86 processor. Each vmspace (or pmap) has unique PCID with the patch, at least until PCID space (12bit) is not exhausted. To really exhaust it, you need 4095 processes, so it is unlikely but possible event with the current settings.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:23 UTC