Re: [Scst-devel] Updated QLogic Drivers to use patched 2.6 kernel driver.

[Nathaniel C. <uto...@mi...>]

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
>>>>>>
>>>>>>      
>>>>>
>>>>
>>>>  
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>