Most software engineers, when asked how they would approach designing and implementing a particular component, will always say something about unit tests. Especially so if put on the spot in an interview setting. Yet, examining something like the Linux kernel, Xen or Tiano Core UEFI, you see plenty of new complex code that has no unit or component testing anywhere in sight.
Sunday, January 29, 2012
Varying SCSI queue depth for VMware PVSCSI block devices.
I was toying with the block subsystem a bit in a Linux virtual machine running under ESX 5.0, when I realized
I could not change the SCSI queue depth. It turns out that the driver simply didn't implement the interface! It was, however, pretty easy to fix this.
https://github.com/andreiw/andreiw-wip/blob/master/linux/3.2/0001-VMW_PVSCSI-Allow-TCQ-depth-change-through-sysfs.patch
Now you can do something like the following:
The patch should make it to mainline, when the current PVSCSI maintainer, Arvind Kumar, gets it integrated.
Why would you care? Because /sys/block/sda/device/queue_depth is quite different from /sys/block/sda/queue/nr_requests. nr_requests controls the request flow before the I/O scheduler, while queue_depth controls the flow of actual dispatch on I/O device. You might be interested in either of those if you run with multiple VMDKs, have an intensive I/O workload on one disk, and notice starvation on others.
I could not change the SCSI queue depth. It turns out that the driver simply didn't implement the interface! It was, however, pretty easy to fix this.
https://github.com/andreiw/andreiw-wip/blob/master/linux/3.2/0001-VMW_PVSCSI-Allow-TCQ-depth-change-through-sysfs.patch
Now you can do something like the following:
# for i in {a..z}; do eval 'echo 1 > /sys/block/sd$i/device/queue_depth'; done
The patch should make it to mainline, when the current PVSCSI maintainer, Arvind Kumar, gets it integrated.
Why would you care? Because /sys/block/sda/device/queue_depth is quite different from /sys/block/sda/queue/nr_requests. nr_requests controls the request flow before the I/O scheduler, while queue_depth controls the flow of actual dispatch on I/O device. You might be interested in either of those if you run with multiple VMDKs, have an intensive I/O workload on one disk, and notice starvation on others.
PE32+
One gloomy evening I decided to look at the latest Portable Executable specification, and thought it would
be pretty cool to write a PE loader.
Doing so under Linux is not particularly difficult, given the binfmt infrastructure, already well used to support legacy and emulation targets.
Two gloomy evenings later I had something that could load a rudimentary PE-COFF executable :-). It doesn't handle an IAT yet, so no shared objects, and since I was in a hurry and tired, no relocations and section alignment must equal file alignment, but I'll work those three out eventually.
Since I didn't have a PE tool chain on hand, I assembled the headers manually, kindly borrowing from them Tiny PE work.
So, uh, why? Firstly, because I can. It's fun, and it exposes me to those parts of the kernel that you don't have much opportunity otherwise to meddle in (and where the learning curve is steeper than usual). But I was lately
wondering what it would take to run the ReactOS userspace under Linux... So you could say my end goal is
write an NT personality for Linux, so I can run an unmodified ReactOS smss.exe with an unmodified ntdll.dll.
Anyway, as usual, the patch against 3.2+ and example hello.asm on my Github account -
https://github.com/andreiw/andreiw-wip/tree/master/linux/3.2/pe32+
Have fun!
be pretty cool to write a PE loader.
Doing so under Linux is not particularly difficult, given the binfmt infrastructure, already well used to support legacy and emulation targets.
Two gloomy evenings later I had something that could load a rudimentary PE-COFF executable :-). It doesn't handle an IAT yet, so no shared objects, and since I was in a hurry and tired, no relocations and section alignment must equal file alignment, but I'll work those three out eventually.
Since I didn't have a PE tool chain on hand, I assembled the headers manually, kindly borrowing from them Tiny PE work.
So, uh, why? Firstly, because I can. It's fun, and it exposes me to those parts of the kernel that you don't have much opportunity otherwise to meddle in (and where the learning curve is steeper than usual). But I was lately
wondering what it would take to run the ReactOS userspace under Linux... So you could say my end goal is
write an NT personality for Linux, so I can run an unmodified ReactOS smss.exe with an unmodified ntdll.dll.
https://github.com/andreiw/andreiw-wip/tree/master/linux/3.2/pe32+
Have fun!
Subscribe to:
Posts (Atom)