In message <[EMAIL PROTECTED]>,"Herbert Huber Zi. 2525" writes: >Hmmmm..., what implications are possible increasing MAX_KMALLOC_SIZE to >PAGE_SIZE? Wouldn't be your first suggestion a little bit more save?
increasing retry seems like a good idea (increasing it to forever is probably the 'right' thing). however, its already 10 and the sleep is 1 second. that seems like a very long time to me. increasing MAX_KMALLOC_SIZE seems like a good idea at this point. it was previously 128k-1 (the max you could alloc with kmalloc). kmalloc isnt the best choice for large chunks of memory (unless you have a special case like dma). however, for things less than the size of a page kmalloc is more efficient than vmalloc and more likely to succeed. i picked the smallest constant size that afs allocates as the dividers. picking the platforms page size might be wiser. previously (before i tampered with it) osi_alloc_linux() would drop the glock. this created trouble with the event management routines on linux. its possible (but unlikely in my opinion) that the other afs 'threads' had eaten all the available memory and are waiting for the glock to drop so that they can free it. we could add an extra flag to osi_alloc_linux() that indicates if its safe to drop the glock. comments? _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
