Wait... It takes ~1ms to write a line to a log file?
The mystery of the fifteen-millisecond breakpoint instruction
11–20 of 50 posts
Re: The mystery of the fifteen-millisecond breakpoint instruction
#12Wait... It takes ~1ms to write a line to a log file?
disk is slow, seems reasonable.
Re: The mystery of the fifteen-millisecond breakpoint instruction
#13This reminds me of one thing I hit 2 years ago, where several android mobile devices would be slow to call signal handlers, because the kernel was booted with user_debug=31(on production devices), which printk stack traces before calling signal handlers. The kernel command line argument was hardcoded on some code aurora branches for Qualcomm boards, iirc.
Re: The mystery of the fifteen-millisecond breakpoint instruction
#14[deleted]
Re: The mystery of the fifteen-millisecond breakpoint instruction
#15There's apparently an even worse usermode-triggerable denial of service in the Pi related to breakpoints, one that allows usermode code to completely hang it: http://hackaday.com/2015/08/25/raspberry-pi-halt-and-catch-w...
Re: The mystery of the fifteen-millisecond breakpoint instruction
#16Wait... It takes ~1ms to write a line to a log file?
disk is slow, seems reasonable.
Don't forget the Pi (generally) uses flash. So seek speeds are irrelevant.
If you're writing the following in 1ms:
Apr 4 22:50:59 heating kernel: [14572.940927] Unhandled prefetch abort: breakpoint debug exception (0x002) at 0x00008438
That means that you're writing to flash at ~1 Mb/s. (~125KB/s) That's slow, to put it mildly. (~5% of what it should be, according to http://ozzmaker.com/2012/12/27/how-to-test-the-sd-card-speed... ) I could see that kind of speed if it was causing a disk seek every write (although if it was doing that you're probably using the wrong file system), but again, the Pi uses flash.
So what gives? Is there braindead sync behavior that's causing it? Is it hitting a pathological case in the flash controller? Or what?
(For that matter: is there a file system that is optimized for log files?)
Re: The mystery of the fifteen-millisecond breakpoint instruction
#17[deleted]
Is that necessary? Do try less hard, please.
Re: The mystery of the fifteen-millisecond breakpoint instruction
#18Earlier quoted context omitted.
disk is slow, seems reasonable.
Don't forget the Pi (generally) uses flash. So seek speeds are irrelevant. If you're writing the following in 1ms: Apr 4 22:50:59 heating kernel: [14572.940927] Unhandled prefetch abort: breakpoint debug exception (0x002) at 0x00008438 By my count that's ~1 kilobit. That means that you're writing to flash at ~1 Mb/s. (~125KB/s) That's slow, to put it mildly. (~5% of what it should be, according to http://ozzmaker.com…
Just read the second comment on the link you provided and you have the answer.
Re: The mystery of the fifteen-millisecond breakpoint instruction
#19Earlier quoted context omitted.
Don't forget the Pi (generally) uses flash. So seek speeds are irrelevant. If you're writing the following in 1ms: Apr 4 22:50:59 heating kernel: [14572.940927] Unhandled prefetch abort: breakpoint debug exception (0x002) at 0x00008438 By my count that's ~1 kilobit. That means that you're writing to flash at ~1 Mb/s. (~125KB/s) That's slow, to put it mildly. (~5% of what it should be, according to http://ozzmaker.com…
Just read the second comment on the link you provided and you have the answer.
> Nowaday’s fast Class 10 cards achieve their high read and write speeds only by buffering in advance, assuming that the subsequent blocks will be read or written next. That means they inevitably sacrifice random read and write speeds. This effect is in the order of several magnitudes. For instance, a card with sequential read and write speeds of 10 MB/s might collapse to just 0.01 MB/s for random access.
Yow. Yet another example of over-optimization to benchmarks.
...Except that, even then, how exactly is appending to a log file repeatedly random access? Bad journaling?
Re: The mystery of the fifteen-millisecond breakpoint instruction
#20Earlier quoted context omitted.
Just read the second comment on the link you provided and you have the answer.
> Nowaday’s fast Class 10 cards achieve their high read and write speeds only by buffering in advance, assuming that the subsequent blocks will be read or written next. That means they inevitably sacrifice random read and write speeds. This effect is in the order of several magnitudes. For instance, a card with sequential read and write speeds of 10 MB/s might collapse to just 0.01 MB/s for random access. Yow. Yet an…
Test