On 07/09/2010 12:36 AM, Jan Friesse wrote: > Steven Dake napsal(a): >> On 07/08/2010 06:39 AM, Jan Friesse wrote: >>> Steven Dake wrote: >>>> In a recent patch to validate that shared memory is actually available >>>> for use, Angus used a write call with 64 byte writes at a time to >>>> validate the space was available before mmap()ing. This results in alot >>>> of write() syscalls which is slowing down ipc connection creation. >>>> >>>> This patch uses a page sized write() call. >>>> >>>> Regards >>>> -steve >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Openais mailing list >>>> [email protected] >>>> https://lists.linux-foundation.org/mailman/listinfo/openais >>> >>> Steve, >>> >>> >>> + } >>> + memset (buffer, 0, page_size); >>> + for (i = 0; i< (bytes / page_size); i++) { >>> retry_write: >>> >>> Seems correct, but it isn't. Let's say, page_size is 4096 and you want >>> preallocate 4093 bytes. Code will not work as expected. >>> >> >> bytes should always be a multiple of the page size, resulting in a >> correct division every time. > > Should be and in current code really is. > >> >> How does a user preallocate 4093 bytes? >> > > Problem is, that coroipcc_service_connect is public API, so > user/developer can call it with request_size 4093 bytes. >
Yes this is a problem in the api implementation. It should either a) automatically make those allocations page sized, or b) reject the operation with an error code. I prefer A - probably something angus can pick up in libqb. > Also from API perspective (even internal) it's not so bad idea to > somehow deal with weird situations like that and it really doesn't > matter too much if dealing is "make it correctly" or return -1 if bytes > % page_size != 0. > > > Regards, > Honza > >> Regards >> -steve >> >>> Take a look to my patch for whitetank, where exactly this is solved. >>> >>> Regards, >>> Honza >> > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
