On Fri, Apr 19, 2013 at 6:52 PM, Martin Sucha <[email protected]> wrote: > On 04/19/2013 05:49 PM, Jiří Zárevúcky wrote: >>> have you tried tester pingpong? >>> it should give an idea about ipc perf limits. >>> >> >> 6490 rt/s > The pingpong test doesn't create a new fibril for each received IPC > message, whereas notification handling does. Is this necessary? Why > don't we have just one fibril handling all notfications just like there > is a single fibril handling messages from a client? This would reduce > the (unnecessary) overhead of creating/destroying a fibril for each > message without any drawback I can think of (the async framework doesn't > do any routing for notifications anyway). > > So the notification handler fibril/function might look like this > (compare with connection handler function): > void handle_notification(void) { > loop { > callid = async_get_notification(&call); > somehow_handle_the_notification(callid, call); > } > }
using separate fibrils for each interrupt allows you to handle them in different paths and asynchronously. In this case it might not be necessary (you still have different paths for ps2a and ps2b), but some device drivers might make use of it. Interrupts that arrived later can be handled sooner/faster. examles that come to mind: Full duplex audio that handles recording and playback separately (different fragment sizes, formats,...). graphics cards that need to handle vblank interrupts ASAP without waiting for output connect/disconnect handlers. ideally there would be more ways to handle interrupts, one fibril, #cpu fibrils, dynamic fibrils, so that each driver can select the most suitable handler in reality I don't think this is a real problem now (after the stack size was reduced to 1 page). the buggy situation combines extremely slow host (emulated noKVM), with extremely intensive workload, in reality ps2 is limited to max 200 Hz (usually 120Hz), and if the mouse was connected via USB it would require less ipc messages. reaching double digit CPU utilization by moving a mouse is not ok, so we might still need this kind of optimization in some cases. Jan > > Martin Sucha > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
