Page 1 of 1
Pipelining system calls?
Posted: Thu Oct 18, 2007 11:01 pm
by earlz
Ok, so I was thinking about how context switching is probably the most expensive thign that is commonly done...(aside from task switching)
so, I was thinking...
what if each time a system call was done by a process, if it was added to a stack/list.... then, a process switch is done, and if another system call is doen, then add it to the list and switch processes, and when the current process is waiting on a system call, just do all the system calls in the stack, therefore making it cause only one context switch and such for that...
anyone kind of understand what I mean?
Posted: Fri Oct 19, 2007 2:13 am
by os64dev
I get the idea, i think but who maintains the stack/list. i mean how can process 1 or process 2 add to a shared stack/list. Via a system call ? that would require a context switch anyways rendering the idea useless. how ever you could pipe systemcalls in a single process/thread. If a process would need to do more then one systemcall though i can't think of a situation yet.
Posted: Fri Oct 19, 2007 3:57 am
by JamesM
But when a process issues a system call it is then destined to wait until that syscall has finished (it can't do anything else until!) so in effect anything that 'queues' or 'delays' syscalls is going to affect latency adversely.
Posted: Fri Oct 19, 2007 4:44 am
by os64dev
JamesM wrote:But when a process issues a system call it is then destined to wait until that syscall has finished (it can't do anything else until!) so in effect anything that 'queues' or 'delays' syscalls is going to affect latency adversely.
consider the following:
i want to map virtual memory segments say for instance 2 MiB to several locations in memory. (is the case with PlayStation memory shadowed at other addresses)
Code: Select all
char buffer[2*1024*1024];
vmap_user(0x00000000, buffer, sizeof(buffer));
vmap_user(0x80000000, buffer, sizeof(buffer));
vmap_user(0xA0000000, buffer, sizeof(buffer));
each of the vmap_user calls would do a context switch. If you could queue these calls as proposed, the same actions could be done with one context switch. Saving two switches and a lot of cpu cycles.
Posted: Fri Oct 19, 2007 5:04 am
by JamesM
Point taken, but most syscalls return a value or error code, making them synchronous. If you can find a way to avoid this, I'd be interested to know
Posted: Fri Oct 19, 2007 5:09 am
by os64dev
In micro kernel the L4 set the standard going from asynchronous to synchronous which btw gave an enormous speed increase. So i am very reluctant to make asynchronous again. But for monolithic kernels it might work.
Posted: Fri Oct 19, 2007 8:20 am
by Avarok
Simple.
Instead of passing single parameters and returning instantly, instead pass a stack, and loop until it's empty. (pass an array on the stack and loop through it?)
You can try using RBP-RSP as an indicator, or JECXZ or whatever suits ya.
System calls are expensive enough to write everything as a loop over arguments if one in 10 calls you pass 2 sets of arguments.
Or so.
Posted: Fri Oct 19, 2007 8:42 am
by JamesM
How does that solve the synchronous problem?