[PATCH] uthum(4) calibration message fix
Hello,
The message of uthum(4)'s calibration offset is incorrect
when the offset is -1 < degC < 0.
I wrote the patch and it is oked by yuo@ (via twitter[1]),
but two months has passed. So I send the patch to tech@ to check again.
ok?
[1] https://twitter.com/uaa/status/362275395430658049
SASANO Takayoshi
Index: uthum.c
===
RCS file: /cvs/src/sys/dev/usb/uthum.c,v
retrieving revision 1.23
diff -u -p -r1.23 uthum.c
--- uthum.c 8 May 2013 08:26:25 - 1.23
+++ uthum.c 26 Sep 2013 20:28:12 -
@@ -820,15 +820,19 @@ uthum_print_sensorinfo(struct uthum_soft
printf("type %s (temperature)",
uthum_sensor_type_s[s->dev_type]);
if (s->cal_offset)
- printf(", calibration offset %d.%d degC",
- s->cal_offset / 100, abs(s->cal_offset % 100));
+ printf(", calibration offset %c%d.%d degC",
+ (s->cal_offset < 0) ? '-' : '+',
+ abs(s->cal_offset / 100),
+ abs(s->cal_offset % 100));
break;
case SENSOR_HUMIDITY:
printf("type %s (humidity)",
uthum_sensor_type_s[s->dev_type]);
if (s->cal_offset)
- printf("calibration offset %d.%d %%RH",
- s->cal_offset / 100, abs(s->cal_offset % 100));
+ printf("calibration offset %c%d.%d %%RH",
+ (s->cal_offset < 0) ? '-' : '+',
+ abs(s->cal_offset / 100),
+ abs(s->cal_offset % 100));
break;
default:
printf("unknown");
Re: pthread_getspecific is too slow
I think _spinlock is suboptimal, although that's not the real problem
as far as my code is concerned. Spinlock is a loop:
while (_atomic_lock(&lock->ticket)) _sched_yield();
This causes a system call every time the lock is held by another thread.
In many cases the spinlock protects a simple operation, e.g. setting a
bit or inserting an item into a list. These operations will complete
in less than 100 cycles (two atomics and a few memory references).
Performance might be improved by polling the lock for a while before
giving up and waiting:
int i = 0;
/* If the lock is held, wait a little for it to become free before
doing expensive scheduling operations. */
while (i++ < 50 && lock->ticket)
asm("pause"); /* x86-specific instruction for use in polling loops */
while (_atomic_lock(&lock->ticket))
_sched_yield()
The pause instruction tells modern x86 processors not to get too
aggressive unrolling the loop. Normal behavior hurts performance
when the loop is polling memory waiting for a change.
Re: pthread_getspecific is too slow
I attached a program showing the slowdown. It spawns threads that call
pthread_getspecific in a tight loop. On Linux the wall clock time is
essentially constant for number of threads up to number of processors.
On OpenBSD 5.3 wall clock time increases approximately linearly with
number of processors.
First argument is number of threads. Second argument is number
of loop iterations. The default count on my system gives about
0.4 seconds per active thread. My system is:
cpu0: AMD Phenom(tm) II X4 955 Processor, 3211.18 MHz
cpu1: AMD Phenom(tm) II X4 955 Processor, 3210.78 MHz
cpu2: AMD Phenom(tm) II X4 955 Processor, 3210.78 MHz
cpu3: AMD Phenom(tm) II X4 955 Processor, 3210.78 MHz
> We haven't done a lot of work to optimize performance except in
> response to specific issues. Sounds like you found one. Would you
> mind providing a test case? I just want to make sure we fix the
> right thing.
#include
#include
#include
#include
const int verbose = 0;
struct data {
pthread_key_t key;
long count;
};
void fn(pthread_key_t key, long count)
{
long i;
pthread_setspecific(key, "hi!");
for (i = 0; i < count; i++) {
void *v = pthread_getspecific(key);
assert(v);
}
return;
}
void *tstart(void *x)
{
struct data *d = (struct data *)x;
if (verbose)
fputs("Starting thread\n", stdout);
fn(d->key, d->count);
if (verbose)
fputs("Stopping thread\n", stdout);
return 0;
}
#define MAXTHREAD 10
void spawn(pthread_key_t key, int nthreads, long count)
{
pthread_t *threads;
struct data d;
int i, rv;
threads = malloc(nthreads * sizeof (pthread_t));
assert(threads);
d.key = key;
d.count = count;
for (i = 0; i < nthreads; i++) {
rv = pthread_create(&threads[i], NULL, tstart, &d);
assert(!rv);
}
for (i = 0; i < nthreads; i++) {
void *rptr = "";
rv = pthread_join(threads[i], &rptr);
assert(!rv);
assert(!rptr);
}
}
int main(int argc, char *argv[])
{
int nthreads = 3;
long niter = 2000;
pthread_key_t key;
int rv;
struct timeval t0, t1;
long dts;
int dtu;
if (argc > 1) {
nthreads = atoi(argv[1]);
if (nthreads < 1 || nthreads > 100) {
fputs("Thread count must be integer in range 1..100\n", stderr);
return 1;
}
}
if (argc > 2) {
niter = atol(argv[2]);
if (niter < 1) {
fputs("Iteration count must be a positive integer\n", stderr);
return 1;
}
}
rv = pthread_key_create(&key, 0);
assert(!rv);
rv = gettimeofday(&t0, 0);
assert(!rv);
spawn(key, nthreads, niter);
rv = gettimeofday(&t1, 0);
assert(!rv);
rv = pthread_key_delete(key);
assert(!rv);
dts = (long)t1.tv_sec - (long)t0.tv_sec;
dtu = (int)t1.tv_usec - (int)t0.tv_usec;
if (dtu < 0) {
dtu += 100;
dts -= 1;
}
assert(dts >= 0);
assert(dtu >= 0);
printf("Time (%d threads, %ld iterations) = %ld.%03u\n",
nthreads, niter, dts, dtu / 1000);
return 0;
}
Re: openbsd ioctl fix (in6.c)
ping ? On Wed, Sep 18, 2013 at 11:01 AM, Loganaden Velvindron wrote: > On Tue, Aug 27, 2013 at 10:37:30AM +0200, Martin Pieuchot wrote: >> On 22/08/13(Thu) 23:31, Claudio Jeker wrote: >> > On Wed, Aug 21, 2013 at 09:59:56AM -0700, Loganaden Velvindron wrote: >> > > I'm not sure if applies to OpenBSD as well, but NetBSD >> > > also disallowed SIOCSIFDSTADDR for ioctl. >> > > [...] >> > > >> > > Index: sys/netinet6/in6.c >> > > === >> > > RCS file: /cvs/src/sys/netinet6/in6.c,v >> > > retrieving revision 1.117 >> > > diff -u -p -r1.117 in6.c >> > > --- sys/netinet6/in6.c13 Aug 2013 05:52:25 - 1.117 >> > > +++ sys/netinet6/in6.c21 Aug 2013 15:50:00 - >> > > @@ -429,8 +429,9 @@ in6_control(struct socket *so, u_long cm >> > > sa6 = &ifr->ifr_addr; >> > > break; >> > > case SIOCSIFADDR: >> > > + case SIOCSIFDSTADDR: >> > > /* >> > > - * Do not pass this ioctl to driver handler since it is not >> > > + * Do not pass those ioctl to driver handler since they are not >> > >* properly setup. Instead just error out. >> > >*/ >> > > return (EOPNOTSUPP); >> > >> > Are any of our driver ioctl handlers handling SIOCSIFDSTADDR? I don't >> > think so but I think this could be just extra safety and should therefor >> > be commited. >> >> Only tun(4) seems to have some code for it, but I don't think it is >> correct. And if it is, we should probably use SIOCGIFDSTADDR_IN6 >> anyway. >> >> Maybe a small cleanup can be done? >> >> So I'm also in favor of this supplementary safety check, and I >> would even add SIOCSIFBRDADDR to this list. > > And SIOCSIFNETMASK as well to be safe ? > > Index: in6.c > === > RCS file: /cvs/src/sys/netinet6/in6.c,v > retrieving revision 1.118 > diff -u -p -r1.118 in6.c > --- in6.c 26 Aug 2013 07:15:58 - 1.118 > +++ in6.c 18 Sep 2013 06:54:13 - > @@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm > sa6 = &ifr->ifr_addr; > break; > case SIOCSIFADDR: > + case SIOCSIFDSTADDR: > + case SIOCSIFBRDADDR: > + case SIOCSIFNETMASK: > /* > -* Do not pass this ioctl to driver handler since it is not > +* Do not pass those ioctl to driver handler since they are > not > * properly setup. Instead just error out. > */ > return (EOPNOTSUPP); >> >> M. >> > -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
[PATCH] (amd64) VIA CPU feature set detection
Patch below allows the kernel (amd64) to detect CPU features (VIA PadLock,
temperature sensors, etc.) on modern VIA Eden CPUs.
My apologies for the previous substandard overly-verbose message.
Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.50
diff -u -p -r1.50 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 24 Aug 2013 23:45:31 - 1.50
+++ sys/arch/amd64/amd64/identcpu.c 26 Sep 2013 08:45:46 -
@@ -568,7 +568,7 @@ identifycpu(struct cpu_info *ci)
if (!strcmp(cpu_vendor, "AuthenticAMD"))
amd64_errata(ci);
- if (strncmp(mycpu_model, "VIA Nano processor", 18) == 0) {
+ if (!strcmp(cpu_vendor, "CentaurHauls")) {
ci->cpu_setup = via_nano_setup;
#ifndef SMALL_KERNEL
strlcpy(ci->ci_sensordev.xname, ci->ci_dev->dv_xname,
