On 02/03/10 11:52, Jordi Espasa Clofent wrote:
So I guess my question is, 'why do you need I/O scheduling, and what
aspect of system performance are you trying to solve with it' ?
Some shell-scripts based on dd or rsync, for example. Even a daily
antivirus (ClamAV) scanner means an extensive I/O.
Even just renicing the processes should help here. The thread(s) will
still be scheduled to run when they need running, although it will
reduce the rate at which the process(es) involved can saturate the
kernel with I/O requests.
Currently the FreeBSD kernel doesn't really make a distinction between
I/O transactions per process, because of how the unified VM buffer cache
works. read() and write() are satisfied from VM; VFS will cause a
vm_object to be created for each opened vnode, so read() will be
satisfied by the same set of vm_page's as for mmap().
The vnode_pager's getpages() routine will eventually read into physical
pages, using BIO requests (although it's usually the filesystem which
actually does this). The net effect is that VFS shares its buffers with
VM, and this does have some piecemeal benefit as the BIO subsystem will
read from the physical medium in large chunks.
It isn't impossible to account for I/O per-process. The Xen hypervisor
has a similiar problem for per-domain I/O accounting. Currently, Domain
0 is responsible for block I/O, and it can be difficult for its
scheduler to tell things apart for similar reasons.
There have been previous research forks of FreeBSD to implement I/O
scheduling; Eclipse/BSD from Bell Labs was one of them. It might be a
good Google Summer of Code project for an interested computer science
student.
cheers,
BMS
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
