In message <[EMAIL PROTECTED]>,"Srikanth Vishwanathan" writes: >One thread was stuck in vmalloc (disk sleep) trying to allocate >memory. Another thread was trying to free memory but it could >not because afs_linux_alloc_sem was taken.
i am guessing that's not a problem anymore since you seem to drop the semaphore being calling vmalloc/kmalloc now. if this is really a problem, i suppose the semaphore could changed to r/w spinlocks. you could get a r/o lock before free so that could find the type of memory, free, and then a r/w lock to remove it from the pool. >I guess we drop GLOCK because there is a possibility that alloc >might sleep in vmalloc under heavy load and we don't want to >lock up the system for so long, which is probably a good idea. actually, i think i would have to disagree due to the number of strange side effects this could cause, like the event mechanism. other os's (as you have mentioned) dont drop the lock. i am beginning to think this is a bad idea since various part of the afs code dont seem to expect alloc's to drop glock. >I guess the max size was chosen simply because that's the >maximum memory that kmalloc can allocate. that seems like a pretty weak reason to use kmalloc for large memory regions. tying down large chunks of memory with kmalloc is only going to exacerbate problems with vmalloc et al. >Someone needs to try this out. Like you said, AFS only allocates >and never frees memory. Is is possible that vmallocing too >much memory could result in a problem ? vmalloc is meant for allocating large chunks of memory. kmalloc shouldnt be used for this unless you absolutely need the pages contiguous in physical memory. this will put more stress on the paging system in the linux kernel but memory should be considered a limited resource. i am already running this change now. seems fine. i would hazard that afs seems to start faster but that could just be a placebo effect. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
