(Not moving to misc@ as I expect this to be the last correspondence
round on this topic)
On 2017-04-05 17:36, Theo de Raadt wrote:
On 2017-04-05 17:24, Theo de Raadt wrote:
>> "ls -l /dev/rsd0c; ls -l /dev/sd0c" shows that sd0c is a block device
>> and rsd0c is a character device, and mmap's man page says that
>> "character special files" are OK.
>
> The manual pages will never list all restrictions.
/dev/sd* delivers ~120MB/sec globally, whereas /dev/rsd* delivers
~575MB/sec, sustainedly in my tests, likely due to lots of the IO
subsystem being bypassed on /dev/rsd* access, as discussed in the
misc@
ML thread with David Gwyne.
So presently higher-speed access is restricted to read()/write() -
noted.
So what?
Yeah you're right - while some really nice code out there such as LMDB
depends on mmap, and mmap may be a bliss in how it abstracts away the
externality of a file from the programmer and from a program, then, of
course mmap is not a panacea or anything and I guess there are some
level of relevant security arguments against it.
I totally understand that rsd* is special and there's no point with
mmap:ing it, so normal access should be done on sd* . So then this
question transforms into the fairly recent what-about-higher-sd* speeds
through multithreading and perhaps multiqueing misc@ thread with David
Gwyne on https://marc.info/?t=148660831800001&r=1&w=2 .
He talked about that the file IO subsystem is singlethreaded and he had
made several but not all parts threadsafe, and so that it's a deep &
implementation question, and he didn't have the time to go into any
additional detail yet.
So I guess the prudent user behavior here would be to wait for very many
months, and to donate.
(Also meanwhile, if I understood him right he hinted that some IO
subsystem hacks he has do give him higher speeds, interesting.)
