Re: CVS commit: src/sys/compat

2012-01-04 Thread Matthias Drochner 

 Module Name:src
 Committed By:   apb
 Date:   Wed Jan  4 13:45:55 UTC 2012
 Modified Files:
 src/sys/compat/common: kern_time_50.c
 src/sys/compat/sys: clockctl.h
 Log Message: Provide a COMPAT_50 version of the CLOCKCTL_NTP_ADJTIME
 ioctl. When time_t was changed from 32 to 64 bits, this ioctl's number
 was changed from _IOWR('C', 0x4, struct clockctl_ntp_adjtime) to
 _IOWR('C', 0x8, struct clockctl_ntp_adjtime), but the data structure
 did not change, so all the compat code has to do is change the number
 and try again.

If this just fixes a mistake which doesn't affect a released version,
it should be OK to fix the ioctl number (and send a heads-up to
current-users).

best regards
Matthias





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Kennen Sie schon unsere app? http://www.fz-juelich.de/app

Re: CVS commit: src/sys/arch

2012-01-04 Thread Mindaugas Rasiukevicius 
Chuck Silvers c...@chuq.com wrote:
   Log Message:
   map all of physical memory using large pages.
   ported from openbsd years ago by Murray Armfield,
   updated for changes since then by me.
  
  This is cool, thanks!  Can you add an entry to src/doc/CHANGES?  Also,
  just wondering - did you try any benchmarks?  I would expect reasonable
  improvement.
 
 does it really make sense to list incremental performance improvements
 there? I can add it if folks want, but we don't tend to document misc
 performance improvements that have no API impact outside the kernel.

Yes, we should and do list such changes.  Also, 2.5% is quite good and it
is useful to collect such numbers in doc/CHANGES for marketing purposes.

 as for how much it helps, on a 12-CPU box build.sh release is about 2.5%
 faster.  if I enable __HAVE_CPU_UAREA_ROUTINES so that uareas are also
 accessed this way that gives an additional 0.5% speedup.

Cool!  Any reason why __HAVE_CPU_UAREA_ROUTINES is not enabled by default?

 coincidentally, this almost exactly compensates for the performance hit
 of enabling DIAGNOSTIC.

It really depends on the workload, e.g. effects on sysbench OLTP are quite
visible or e.g. PR/45734.

 
 -Chuck

-- 
Mindaugas

Re: CVS commit: src/sys/compat

2012-01-04 Thread Alan Barrett 

On Wed, 04 Jan 2012, Matthias Drochner wrote:
Log Message: Provide a COMPAT_50 version of the 
CLOCKCTL_NTP_ADJTIME ioctl. When time_t was changed from 32 
to 64 bits, this ioctl's number was changed from _IOWR('C', 
0x4, struct clockctl_ntp_adjtime) to _IOWR('C', 0x8, struct 
clockctl_ntp_adjtime), but the data structure did not change, 
so all the compat code has to do is change the number and try 
again.


If this just fixes a mistake which doesn't affect a released 
version, it should be OK to fix the ioctl number (and send a 
heads-up to current-users).


I think it's OK to break compatibility for current users when it's 
been only a short time since the change, but it's now been about 
three yers since the 64-bit time_t changes, so I really don't want 
to break compatibility.


--apb (Alan Barrett)