Re: [VFS] move active filesystem

Re: [VFS] move active filesystem

[Andrea Arcangeli]

On Tue, 18 May 1999, Chris Wedgwood wrote:

>> And what about a more inteligent DMA memory allocator ? I mean, in
>> case of fragmented memory it's very frequent not to success to
>> allocate DMA memory by kernel (eg by sound/floppy modules). Why
>> does not kernel moves some memory, changing some pagetable entries
>> etc to create contigous memory area suitable for DMA (in low 16M
>> for ISA DMA, care of page boundaries etc). If there's enough memory
>> to do it, it would be only some memory moving action to get the
>> suitable place.
>> 
>> (I don't know too much about Linux kernel internals, maybe DMA
>> memory allocating is something atomic operation which blocks the
>> kernel too long to do such an operation I described below ?)
>
>Right now, we can't tell which pages are in use by what, so moving

Not really. We obviously can, but not in O(1). I could just add the logic
to have the information in O(1), but then you must know that at every
allocation you'll have to insert a entry in a queue, and remove an entry
from a queue at every umapping/freeing of memory. Anyway I'll think I'll
do that very soon to improve and simplify a lot my update_shared_mappings
and many other similar thing in order to handle all such things in O(1).
(and btw with such info my new shrink_mmap will be also able to unmap and
free page/swap cache directly from the pagemap-lru (I am talking about my
current code, the stock kernel doesn't have a real lru))

BTW, allowing dirty pages in the page cache may avoid I/O to disk but
won't avoid memcpy data to the page cache even if the page cache was just
uptdate. So I am convinced right now update_shared_mappings() is the right
thing to do and it's not an dirty hack. It's only a not very efficient
implementation that has to play with pgd/pmd/pte because we don't have
enough information (yet) from the pagemap.

Andrea Arcangeli

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: [VFS] move active filesystem

[Chris Wedgwood]

> Not really. We obviously can, but not in O(1).

Indeed... but not for arbitrary pages (eg. locked by other
susbsystems, drivers or applications)

> I could just add the logic to have the information in O(1), but
> then you must know that at every allocation you'll have to insert a
> entry in a queue, and remove an entry from a queue at every
> umapping/freeing of memory. Anyway I'll think I'll do that very
> soon to improve and simplify a lot my update_shared_mappings and
> many other similar thing in order to handle all such things in
> O(1).

Won't this be fairly expensive?





-cw
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: [VFS] move active filesystem

[Stephen C. Tweedie]

Hi,

On Wed, 19 May 1999 18:28:04 +0200 (CEST), Andrea Arcangeli
<andrea@suse.de> said:

> BTW, allowing dirty pages in the page cache may avoid I/O to disk but
> won't avoid memcpy data to the page cache even if the page cache was just
> uptdate. So I am convinced right now update_shared_mappings() is the right
> thing to do and it's not an dirty hack. It's only a not very efficient
> implementation that has to play with pgd/pmd/pte because we don't have
> enough information (yet) from the pagemap.

To do it correctly, you need to do much more than just play with the
page tables in the way your current update_shared_mappings() does,
because the page can be at different addresses in different VAs.  For
MAP_SHARED pages we have a list of all the VAs, but for MAP_PRIVATE
pages we do not, and mremap() can still cause a shared private page
(eg. data pages after fork()) to appear at different locations in
different mms. 

Dealing with that is a little tricky, but you can do it by keeping lists
of "related" vmas, based on overlaps between the original addresses of
the vmas, not their current addresses.  Private page sharing can only
occur when the original address of the vmas overlapped, and that gives
us an invariant to check for over mremap().

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/