> It disables out-of-order execution by the processor, so there's a
> pipeline stall.
we know there's going to be a stall already, since we can't get
the cacheline we're looking for.
> There's overhead to calling the tsc instructions, but not that much.
>
> Does `srb->wmach != m->machno` imply th
2014-06-20 7:50 GMT-04:00 erik quanstrom :
> On Fri Jun 20 01:04:20 EDT 2014, devon.od...@gmail.com wrote:
>
>> Weird. I assume cycles is using rdtsc or rdtscp. Perhaps some of it is due
>> to a combination of contention and rdtsc(p) being serializing instructions?
I forget that rdtsc isn't, and o
On Fri Jun 20 06:24:25 EDT 2014, p...@fb.com wrote:
good catch, but...
> The code in kbdputsc() in kbd.c does not look very safe:
>
> kbscan->kc[kbscan->nk++] = c; <- no bound checking, can
> overflow.
this behavior depends entirely on what latin1() does. if
latin1() will
On Fri Jun 20 01:04:20 EDT 2014, devon.od...@gmail.com wrote:
> Weird. I assume cycles is using rdtsc or rdtscp. Perhaps some of it is due
> to a combination of contention and rdtsc(p) being serializing instructions?
> On Jun 19, 2014 12:04 PM, "erik quanstrom" wrote:
other than the code i poste
> > the astounding thing is that t1-t0 is often ~ 60,000 cycles.
> > it only hits a small fraction of the time, and the average is
> > much lower. but that just blows the mind. 6 cycles!
> >
> > (other versions with sched were much worse.)
> >
> > as far as i can tell, there are no funny bi
Hi,
There is another buffer overflow somewhere I think.
The code in kbdputsc() in kbd.c does not look very safe:
kbscan->kc[kbscan->nk++] = c; <- no bound checking, can
overflow.
c = latin1(kbscan->kc, kbscan->nk);
if(c < -1) /* need
