From: Nathaniel C. <uto...@mi...> - 2006-01-25 18:44:21
|
Okay here it is now with -p. One other change that's in there: changes to the kernel patch for scst to update it to 2.6.14. - nate Vladislav Bolkhovitin wrote: > Thanks! But, please remake the patch with "-p" diff option. It easies > reading patches a _LOT_. > > Nathaniel Clark wrote: > >> But with the patch this time. >> >> - nate >> >> Nathaniel Clark wrote: >> >> >>> Vladislav Bolkhovitin wrote: >>> >>> >>> >>> >>>> Nathaniel Clark wrote: >>>> >>>> >>>> >>>>> Vladislav Bolkhovitin wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Nathaniel Clark wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> As a side question: how much testing have you done with high >>>>>>> memory? >>>>>>> I've got more than a gig in one of my systems, and it keeps >>>>>>> crashing. >>>>>>> At least some of the time it panics on one of the kmap_atomic >>>>>>> calls. >>>>>> >>>>>> >>>>>> No testing at all, because after I implemented it I realised that >>>>>> enabling it in SCST brings nothing really valuable, at least until >>>>>> fileio stops copying data from the page cache, i.e. will use them >>>>>> directly, and starts leaving SCST allocated pages in the page cache. >>>>>> SCST keeps pages for data buffers allocated only while its commands >>>>>> are being executed. On even highly loaded system there are not too >>>>>> many of them, so about handred of Mb could be consumed at max. (I'm >>>>>> sure you understand, that there is no relation between system >>>>>> capability to use high mem and SCST's one). >>>>>> >>>>>> Thus, I thing that currently benefits of high mem in SCST doesn't >>>>>> worth the effort and performance hit. >>>>>> >>>>>> I wonder, why do you think you need to enable high mem in SCST? >>>>>> >>>>> >>>>> >>>>> Okay I misremembered what SCST_HIGHMEM was used for, I thought it >>>>> was a >>>>> requirement for highmem systems, but I thought /page_address/ didn't >>>>> work all the time in that HIGHMEM environments? Doesn't it fail >>>>> if the >>>>> page isn't mapped and thus require a call to kmap? >>>>> >>>> >>>> >>>> Kmap() is required only for highmem pages. If SCST_HIGHMEM is off SCST >>>> allocates only low mem pages, which are always mapped, so >>>> page_address() is OK for them. >>>> >>> >>> >>> AHA! That is the crucial missing piece of information. Thank you. >>> >>> >>> >>> >>>>>>> I'm just trying to get a handle on home much effort I should put >>>>>>> into >>>>>>> these bugs with a new SCST coming. >>>>>>> >>>>>> >>>>>> >>>>>> If you have time (and I understand you correctly), I will appreciate >>>>>> if you convert in SCST usage of kmalloc for commands, sessions, >>>>>> tgt_dev's and acg_dev's to appropriate slab cashes. Other actual >>>>>> tasks >>>>>> are listed in the ToDo file (most important and interesting one is >>>>>> sgv_pool). >>>>>> >>>>> >>>>> >>>>> I'd be more than happy to drop you a patch w/ kmalloc/kfree -> slab >>>>> cache. >>>>> >>>> >>> >>> This patch is a role up of a couple of changes: >>> * kmalloc/kfree -> slab cache (w/ #ifdef's in case 2.4 doesn't have >>> slab >>> caches, I didn't look). >>> * added new debugging options for inspecting scsi packets passing >>> through scst, 4 separate options for all combinations of recv/send and >>> top/bottom. This makes debugging pieces on either side of SCST >>> easier also. >>> * fix a problem I ran into in scst_process_mgmt_cmd where processes in >>> an intermediate state of executing or done_wait were freed prematurely. >>> * add WRITE_VERIFY's to scst_fileio. >>> >>> >>> >>> >>>>> >>>>> >>>>>> Vlad >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> > > |