From Adrian.Frost at sun.com Fri Aug 10 08:21:01 2007 From: Adrian.Frost at sun.com (Adrian.Frost at sun.com) Date: Fri, 10 Aug 2007 08:21:01 -0700 (PDT) Subject: [intel-platform-dev] sync code with opensolaris and update Intel fma Message-ID: <20070810152101.C66FACB451@mail.opensolaris.org> Author: arf Repository: /hg/intel-platform/onnv-intel-fma Latest revision: 65b9d8cacf16b28dca659b852b34b670b7e910b1 Total changesets: 1 Log message: sync code with opensolaris and update Intel fma Files: update: usr/src/lib/fm/topo/modules/i86pc/chip/mc_intel.c update: usr/src/pkgdefs/SUNW0on/prototype_com update: usr/src/uts/i86pc/intel_nb/nb5000/dimm_addr.h update: usr/src/uts/i86pc/intel_nb/nb5000/intel_nb5000.c update: usr/src/uts/i86pc/intel_nb/nb5000/nb5000.h From sherry.moore at sun.com Thu Aug 16 11:38:39 2007 From: sherry.moore at sun.com (Sherry Moore) Date: Thu, 16 Aug 2007 11:38:39 -0700 Subject: [intel-platform-dev] Thanks a bunch to our Intel colleagues Message-ID: <20070816183838.GI20692@sun.com> I would like to thank our Intel colleagues Ashok (Ashok.Raj at intel.com), Bob (Robert.A.Kasten at intel.com), Rajesh (rajesh.shah at intel.com) and Dave (David.C.Stewart at intel.com) for their significant contributions to the recent putbacks from the Intel project team. 6495392 use monitor/mwait for halting idle CPUs where supported 6558456 Need to support microcode update on Intel platforms 6495401 cpuid based cache hierarchy awareness 6563585 prtconf reports wrong cache-level on x86 systems having 4MB (associative=16, line-size=64) L2 cache 6574102 Need to add extended family/model/stepping info to cpuid_pass1() for Intel processors They helped us in every stage of the projects, including design, coding, reviewing, pre- and post- integration testing. Without their dedication none of the progress would have been possible. Thank you, Ashok, Bob, Rajesh and Dave! - Intel Project Team From Adrian.Frost at sun.com Sat Aug 25 03:56:27 2007 From: Adrian.Frost at sun.com (Adrian.Frost at sun.com) Date: Sat, 25 Aug 2007 03:56:27 -0700 (PDT) Subject: [intel-platform-dev] fix fsb support Message-ID: <20070825105627.4207B33B01@mail.opensolaris.org> Author: arf Repository: /hg/intel-platform/onnv-intel-fma Latest revision: b90c8f432d4d3a83062e4c6ee5af419430ef5f10 Total changesets: 1 Log message: fix fsb support Files: update: usr/src/pkgdefs/SUNW0on/prototype_com update: usr/src/uts/i86pc/intel_nb/nb5000/intel_nb5000.c update: usr/src/uts/i86pc/intel_nb/nb5000/nb5000.h From Bill.Holler at Sun.COM Tue Aug 28 19:12:27 2007 From: Bill.Holler at Sun.COM (Bill Holler) Date: Tue, 28 Aug 2007 19:12:27 -0700 Subject: [intel-platform-dev] Code review for several MONITOR/MWAIT idle loop CRs Message-ID: <46D4D60B.7020404@sun.com> http://cr.opensolaris.org/~bholler/mwait_fixes Here is a webrev code review for the following idle loop MONITOR/MWAIT CRs (Change Requests): 6577948 mach_alloc_mwait leaks memory when a CPU fails to start 6588054 panic() in mach_alloc_mwait() should be changed to degraded operation... 6596141 Solaris should not use an unmodified MWAIT idle loop on AMD 10h due to increased power consumption While these are relatively low priority, I want to get these in soon for maximum S10U5 soak time. Testing completed: 1) The x86 build of this kernel has passed ON PIT DIY. The SPARC build is currently in ON PIT DIY and looks ok. (There are no common changes that should effect SPARC.) 2) libmicro did not regress. PERF PIT is not planned as these are enable/disable changes which should not change performance in either state. 3) The memory leak is fiked in unit testing with all non-boot cpus forced to fail to online using cpufailset debug hook. 4) My desktop has been running this for 2 weeks without incident. Ongoing testing: 1) Barcelona testing is ongoing. 2) 6588054 error injection testing is ongoing. Thank you, Bill Holler From Jim.Grisanzio at Sun.COM Wed Aug 29 07:46:25 2007 From: Jim.Grisanzio at Sun.COM (Jim Grisanzio) Date: Wed, 29 Aug 2007 23:46:25 +0900 Subject: [intel-platform-dev] [intel-platform-discuss] Thanks a bunch to our Intel colleagues In-Reply-To: <20070816183838.GI20692@sun.com> References: <20070816183838.GI20692@sun.com> Message-ID: <46D586C1.6030707@sun.com> Sherry Moore wrote: > I would like to thank our Intel colleagues Ashok (Ashok.Raj at intel.com), > Bob (Robert.A.Kasten at intel.com), Rajesh (rajesh.shah at intel.com) and > Dave (David.C.Stewart at intel.com) for their significant contributions to > the recent putbacks from the Intel project team. > > 6495392 use monitor/mwait for halting idle CPUs where supported > 6558456 Need to support microcode update on Intel platforms > 6495401 cpuid based cache hierarchy awareness > 6563585 prtconf reports wrong cache-level on x86 systems having 4MB > (associative=16, line-size=64) L2 cache > 6574102 Need to add extended family/model/stepping info to > cpuid_pass1() for Intel processors > > > They helped us in every stage of the projects, including design, > coding, reviewing, pre- and post- integration testing. Without their > dedication none of the progress would have been possible. Thank > you, Ashok, Bob, Rajesh and Dave! This is great news. We should get these listed on the contribution grid http://opensolaris.org/os/bug_reports/request_sponsor/. Since these are already complete, I'll look into getting that done. And since more are on the way, you may want to consider using request-sponsor so Bonnie sees these as they flow through and she'll automatically post them. Jim From Bill.Holler at Sun.COM Wed Aug 29 12:28:51 2007 From: Bill.Holler at Sun.COM (Bill Holler) Date: Wed, 29 Aug 2007 12:28:51 -0700 Subject: [intel-platform-dev] [intel-platform-discuss] Code review for several MONITOR/MWAIT idle loop CRs In-Reply-To: <46D5BA76.1020206@sun.com> References: <46D4AC65.8030900@sun.com> <20070829181858.GC218835@eng.sun.com> <46D5BA76.1020206@sun.com> Message-ID: <46D5C8F3.7070708@sun.com> The original implementation (pre-ON-putback) used a kmem_cache which took care of the alignment issues as you mentioned. :-) We changed the implementation to use kmem_alloc() during the original review due to the memory overhead as Joe noted. Thank you, Bill Joe Bonasera wrote: > > Creating a kmem cache for these would waste lots of memory. > Distinct caches have lots of overhead, especially given we > allocate just one of these per processor and don't ever free > or re-allocate them. > > johansen-osdev at sun.com wrote: >> Bill, >> These changes generally quite good. The only thing that I would >> consider changing would be the use of kmem_alloc() and size_actual, >> buf_actual in the struct mwait_info. >> >> If you instead use kmem_cache_alloc() for these structures, you can >> specify the required alignment when you create the cache as part of >> kmem_cache_create(). This assumes that all mwait_info structs will need >> to be aligned to the same boundaries. (I don't know if that's a safe >> assumption in this case.) >> >> Hope that helps, >> >> -j >> >> >> On Tue, Aug 28, 2007 at 04:14:45PM -0700, Bill Holler wrote: >>> http://cr.opensolaris.org/~bholler/mwait_fixes >>> >>> Here is a webrev code review for the following idle loop MONITOR/MWAIT >>> CRs (Change Requests): >>> >>> 6577948 >>> mach_alloc_mwait leaks memory when a CPU fails to start >>> 6588054 panic() >>> in mach_alloc_mwait() should be changed to degraded operation... >>> 6596141 Solaris >>> should not use an unmodified MWAIT idle loop on AMD 10h due to >>> increased power consumption >>> >>> >>> While these are relatively low priority, I want to get these in soon >>> for >>> maximum S10U5 soak time. >>> >>> Testing completed: >>> 1) The x86 build of this kernel has passed ON PIT DIY. The SPARC build >>> is currently in ON PIT DIY and looks ok. (There are no common >>> changes >>> that should effect SPARC.) >>> 2) libmicro did not regress. >>> PERF PIT is not planned as these are enable/disable changes >>> which should >>> not change performance in either state. >>> 3) The memory leak is fiked in unit testing with all non-boot cpus >>> forced to >>> fail to online using cpufailset debug hook. >>> 4) My desktop has been running this for 2 weeks without incident. >>> >>> Ongoing testing: >>> 1) Barcelona testing is ongoing. >>> 2) 6588054 error injection testing is ongoing. >>> >>> Thank you, >>> Bill Holler >>> >>> _______________________________________________ >>> intel-platform-discuss mailing list >>> intel-platform-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/intel-platform-discuss >> _______________________________________________ >> intel-platform-discuss mailing list >> intel-platform-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/intel-platform-discuss > From Bill.Holler at Sun.COM Wed Aug 29 12:49:07 2007 From: Bill.Holler at Sun.COM (Bill Holler) Date: Wed, 29 Aug 2007 12:49:07 -0700 Subject: [intel-platform-dev] [intel-platform-discuss] Code review for several MONITOR/MWAIT idle loop CRs In-Reply-To: <46D5BA76.1020206@sun.com> References: <46D4AC65.8030900@sun.com> <20070829181858.GC218835@eng.sun.com> <46D5BA76.1020206@sun.com> Message-ID: <46D5CDB3.1040606@sun.com> > This assumes that all mwait_info structs will need > to be aligned to the same boundaries. (I don't know if > that's a safe assumption in this case. The code does assume all cpus have the same mwait buffer alignment requirement and size. The boot cpu allocates the mcpu_mwait buffer for other cpus using its own cpuid_pass1 mwait size info. See mp_startup_init() line 252 which executed before the other cpu is online. This is done because the starting cpu cannot idle until its idle data structures are initialized (for example if the starting cpu tries to acquire a held lock). Is it possible for a system to have cpus with different mwait buffer alignment requirements? I assume this would require the cpus have different cache line sizes. Several other parts of the kernel assume all cpus have the same cache line size. Humm. At worst on a hypothetical mixed-mwait-buffer-size-machine the starting cpu could suffer from false sharing of its mcpu_mwait buffer if it requires a larger mwait buffer with different alignment. This could possibly cause false idle wakeups. Due to the way the idle loop works, false wakeup will cause an increased power consumption but does not hurt performance (actually increases performance slightly). Regards, Bill Joe Bonasera wrote: > > Creating a kmem cache for these would waste lots of memory. > Distinct caches have lots of overhead, especially given we > allocate just one of these per processor and don't ever free > or re-allocate them. > > johansen-osdev at sun.com wrote: >> Bill, >> These changes generally quite good. The only thing that I would >> consider changing would be the use of kmem_alloc() and size_actual, >> buf_actual in the struct mwait_info. >> >> If you instead use kmem_cache_alloc() for these structures, you can >> specify the required alignment when you create the cache as part of >> kmem_cache_create(). This assumes that all mwait_info structs will need >> to be aligned to the same boundaries. (I don't know if that's a safe >> assumption in this case.) >> >> Hope that helps, >> >> -j >> >> >> On Tue, Aug 28, 2007 at 04:14:45PM -0700, Bill Holler wrote: >>> http://cr.opensolaris.org/~bholler/mwait_fixes >>> >>> Here is a webrev code review for the following idle loop MONITOR/MWAIT >>> CRs (Change Requests): >>> >>> 6577948 >>> mach_alloc_mwait leaks memory when a CPU fails to start >>> 6588054 panic() >>> in mach_alloc_mwait() should be changed to degraded operation... >>> 6596141 Solaris >>> should not use an unmodified MWAIT idle loop on AMD 10h due to >>> increased power consumption >>> >>> >>> While these are relatively low priority, I want to get these in soon >>> for >>> maximum S10U5 soak time. >>> >>> Testing completed: >>> 1) The x86 build of this kernel has passed ON PIT DIY. The SPARC build >>> is currently in ON PIT DIY and looks ok. (There are no common >>> changes >>> that should effect SPARC.) >>> 2) libmicro did not regress. >>> PERF PIT is not planned as these are enable/disable changes >>> which should >>> not change performance in either state. >>> 3) The memory leak is fiked in unit testing with all non-boot cpus >>> forced to >>> fail to online using cpufailset debug hook. >>> 4) My desktop has been running this for 2 weeks without incident. >>> >>> Ongoing testing: >>> 1) Barcelona testing is ongoing. >>> 2) 6588054 error injection testing is ongoing. >>> >>> Thank you, >>> Bill Holler >>> >>> _______________________________________________ >>> intel-platform-discuss mailing list >>> intel-platform-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/intel-platform-discuss >> _______________________________________________ >> intel-platform-discuss mailing list >> intel-platform-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/intel-platform-discuss >