executing stream: should it be a new concept?
Posted: Wed Jun 01, 2011 7:12 am
hi guys!
days after days, i've been always found my kernel architecture not good enough. but sparks flies these days.
i've been thinking a new thing for kernel, executing stream, which was designed for asynchronous syscalls and higher core performance, will be much lighter-weight than thread, since threads need to setup signal handlers, flags, and attributes so on. And even thread share linear space with other threads within a same process, it have to switch space on scheduling.
what is it like:
1. quick creation and destroy, with limited array with about 1024 elements or so.
2. with only GPREGs, maybe float regs, and ip saved, so a quick switch is ensured.
3. then thread is implemented in a higher level in kernel, and could be as complex as LWP.
4. and message to kernel could be replaced by direct syscalls and we can create executing stream for each stream, avoiding the overhead by message and implementing asynchronous syscalls.
5. every interrupt will create executing stream like syscalls, each executing stream can create a new one when need other kernel modulars, rather than call another part directly( asynchronous might be needed ) or send a message( a bit slow ).
but there are really many problems:
1. it could make kernel much more complex and unstable
2. the function provided might be not enough for a nice run.
3. i havent think clear how it works to handle the interrupt and syscalls
4. i dont know if the benefit metioned before is as i thought to be there
5. the kernel may have to work very differently as my before one, new layer, new relationship and new mechanism
the key point is, much faster switch, much better kernel performance, and asynchronous syscalls;
the risk is, i may waste a lot time like a month and such architecture turn out to be of none use, little performance improving but more complexity and less functional.
i'm hesitating and wish you can figure it out.
thanks!
days after days, i've been always found my kernel architecture not good enough. but sparks flies these days.
i've been thinking a new thing for kernel, executing stream, which was designed for asynchronous syscalls and higher core performance, will be much lighter-weight than thread, since threads need to setup signal handlers, flags, and attributes so on. And even thread share linear space with other threads within a same process, it have to switch space on scheduling.
what is it like:
1. quick creation and destroy, with limited array with about 1024 elements or so.
2. with only GPREGs, maybe float regs, and ip saved, so a quick switch is ensured.
3. then thread is implemented in a higher level in kernel, and could be as complex as LWP.
4. and message to kernel could be replaced by direct syscalls and we can create executing stream for each stream, avoiding the overhead by message and implementing asynchronous syscalls.
5. every interrupt will create executing stream like syscalls, each executing stream can create a new one when need other kernel modulars, rather than call another part directly( asynchronous might be needed ) or send a message( a bit slow ).
but there are really many problems:
1. it could make kernel much more complex and unstable
2. the function provided might be not enough for a nice run.
3. i havent think clear how it works to handle the interrupt and syscalls
4. i dont know if the benefit metioned before is as i thought to be there
5. the kernel may have to work very differently as my before one, new layer, new relationship and new mechanism
the key point is, much faster switch, much better kernel performance, and asynchronous syscalls;
the risk is, i may waste a lot time like a month and such architecture turn out to be of none use, little performance improving but more complexity and less functional.
i'm hesitating and wish you can figure it out.
thanks!