Re: After memory pressure: can't read from tape anymore

[Boaz Harrosh <bharrosh@panasas.com>]

On 11/30/2010 07:04 PM, Kai Makisara wrote:
> On Tue, 30 Nov 2010, Boaz Harrosh wrote:
> 
>> On 11/30/2010 06:23 PM, Kai Makisara wrote:
>>> On Tue, 30 Nov 2010, Boaz Harrosh wrote:
>>>
>>>> On 11/30/2010 03:31 PM, Lukas Kolbe wrote:
>>>>> On Mon, 2010-11-29 at 19:09 +0200, Kai Makisara wrote:
>>>>>
>>> ....
>>>> It looks like something is broken/old-code in sr. Most important LLDs
>>>> and block-layer scsi-ml fully support sg-chaining that effectively are
>>>> able to deliver limitless (Only limited by HW) sg sizes. It looks like
>>>> sr has some code that tries to allocate contiguous buffers larger than
>>>> PAGE_SIZE. Why does it do that? It should not be necessary any more.
>>>>
>>> The relevant driver is st 
>>
>> Sorry I meant st, yes.
>>
>>> and it use sg chaining when necessary. I tried 
>>> to explain that the effective limit in this case comes from mptsas. I 
>>> don't know if it is HW limit or driver limit.
>>>
>>
>> Than I don't understand where is the failing allocation. Where in the
>> code path anyone is trying to allocate something bigger then a page?
>> Please explain?
>>
> The function enlarge_buffer() in st.c tries to allocate a driver buffer 
> that is large enough for one block so that the number of contiguous memory 
> blocks does not exceed the allowed maximum. Allocation is done using 
> alloc_pages() (at line 3744 in st.c in 2.6.36), usually with order > 0.
> 

I looked at enlarge_buffer() and it looks fragile and broken. If you really
need a pointer eg:
	STbuffer->b_data = page_address(STbuffer->reserved_pages[0]);

Than way not use vmalloc() for buffers larger then PAGE_SIZE? But better yet
avoid it by keeping a pages_array or sg-list and operate on an aio type
operations.

> Kai

But I understand this is a lot of work on an old driver. Perhaps pre-allocate
something big at startup. specified by user?

Thanks
Boaz