BALBIR SINGH wrote:
>>
>> There is nothing which avoids us from doing that (there is one reserved
>> pool I remeber right now: the highmem bounce buffering pool, but that
>> one
>> is a special case due to the way Linux does IO in high memory and its
>> only
>> needed on _real_ emergencies --- it will be removed in 2.5, I hope).
>>
>> In general, its a better approach to share the memory and have a unified
>> pool. If a given subsystem is not using its own "reversed" memory,
>> another
>> subsystems can use it.
>>
>> The problem we are seeing now can be fixed even without the reserved
>> pools.
>>
> I agree that is the fair and nice thing to do, but I was talking about
> reserving
> memory for device vs sharing it with a user process, user processes
> can wait,
> their pages can even be swapped out if needed. But for a device that
> is not willing
> to wait (GFP_ATOMIC) say in an interrupt context, this might be a issue.
>
>
> Anyway, how do you plan to solve this ?
> Balbir
I did not realize that highmem was causing this problem you were facing,
anyway my argument
about the pools still holds.
Balbir
>
>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
>
>
>
>------------------------------------------------------------------------
>
>----------------------------------------------------------------------------------------------------------------------
>Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
>is intended for use only by the individual or entity to which it is
>addressed, and may contain information that is privileged, confidential or
>exempt from disclosure under applicable law. If you are not the intended
>recipient or it appears that this mail has been forwarded to you without
>proper authority, you are notified that any use or dissemination of this
>information in any manner is strictly prohibited. In such cases, please
>notify us immediately at mailto:mailadmin@wipro.com and delete this mail
>from your records.
>----------------------------------------------------------------------------------------------------------------------
>
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:25 EST