MM question

MM question

[Jason Titus]

I know this must be on a FAQ or some such, but after many hours of 
newsgroup/web searching - nothing.

Is there a way to turn off/down the page caching and buffering?  I'm doing
database work and am having a really time benchmarking other elements of the
system due to Linux's friendly caching....

I have tried editing /proc/sys/vm/pagecache and buffermem, but the changes
don't seem to do anything (2.2.0-pre5 - x86).  Is there something you have
to do to activate the changes?  Is there some other file to edit to set the
variables at boot time?

It sure would be nice to have more control over the caching, like being able
to have a /etc/cache.conf file where you could set parameters and mark
certain files/filetypes as priority cache items...

Anyway, any help would be much appreciated, and sorry for the ignorant
question,

Jason Titus
jason@iatlas.com
--
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: MM question

[Stephen C. Tweedie]

Hi,

On Mon, 15 Feb 1999 21:30:22 -0500, "Jason Titus" <jason@iatlas.com>
said:

> Is there a way to turn off/down the page caching and buffering?  I'm doing
> database work and am having a really time benchmarking other elements of the
> system due to Linux's friendly caching....

No.

You can tune a few different aspects of the VM's management of the
caches, but there is really no way to disable them completely.

> It sure would be nice to have more control over the caching, like being able
> to have a /etc/cache.conf file where you could set parameters and mark
> certain files/filetypes as priority cache items...

Why exactly do you need it?  For plain benchmarking, the standard
technique to defeat caching is to benchmark on files much larger than
physical memory.  

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

MM question

[Magnus Ahltorp]

I'm working on a Linux port of Arla, a free AFS (a distributed file
system) client. Arla caches whole files, which means that the read and
write file system calls are tunneled through to the cache file system
(usually ext2).

I implement the inode operation readpage for reads and the file
operation write for writes. readpage gets tunneled by creating a new
struct file and filling in the cache inode. write gets tunneled in
much the same way. Though, I have been seeing problems when a file
gets written to. The written data weren't always seen when doing
reads. Someone then suggested that the folloing code be added to
write:

	page = get_free_page(GFP_KERNEL);
	if (!page)
	    invalidate_inode_pages(inode);
	else {
	    int pos = file->f_pos;
	    int cnt = count;
	    int blk;
	    char *data=(char *)page;

	    while (cnt > 0) {
		blk = cnt;
		if (blk > PAGE_SIZE)
		    blk = PAGE_SIZE;
		copy_from_user(data, buf, blk);
		update_vm_cache(inode, pos, data, blk);
		pos += blk;
		cnt -= blk;
	    }
	    free_page(page);
	}

I inserted this piece of code, and things worked quite well. After a
while, I was seeing new problems. Writes were not propagating properly
to the cache file.

Does anyone have any suggestions on how this really should be done?

/Magnus
map@stacken.kth.se
--
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: MM question

[Benjamin C.R. LaHaise]

On 21 Feb 1999, Magnus Ahltorp wrote:
...
> I inserted this piece of code, and things worked quite well. After a
> while, I was seeing new problems. Writes were not propagating properly
> to the cache file.

The code listed is just plain wrong -- it doesn't take into account pages
that are already present in the page cache.  If you need to use this
technique, take a look at mm/filemap.c:generic_file_write for an example
of how to do this properly (mostly, find the page in the page cache, if
not found add it; lock page in page cache). 

> Does anyone have any suggestions on how this really should be done?

Could you clairify how you're doing things?  Are pages cached in the
kernel owned by your filesystem's inode or ext2's?  The hint I'm getting
from the code you quoted is the both are storing the data, which is
inefficient.  The easiest thing to do would be to tunnel all operations to
the ext2 inode -- your filesystem should not have a readpage function.
Rather, mmap(), read() and write() all receive the ext2 inode of the file,
so that all pages in memory are owned by the ext2 inode, and your inode is
merely an indirect handle that validates the cache.  How's that sound?

		-ben



--
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: MM question

[Magnus Ahltorp]

> The code listed is just plain wrong -- it doesn't take into account pages
> that are already present in the page cache.  If you need to use this
> technique, take a look at mm/filemap.c:generic_file_write for an example
> of how to do this properly (mostly, find the page in the page cache, if
> not found add it; lock page in page cache). 

Since I didn't write the code myself, it doesn't express my
intentions, but rather someone else's, so don't look at it too much.

> Could you clairify how you're doing things?  Are pages cached in the
> kernel owned by your filesystem's inode or ext2's?  The hint I'm getting
> from the code you quoted is the both are storing the data, which is
> inefficient.  The easiest thing to do would be to tunnel all operations to
> the ext2 inode -- your filesystem should not have a readpage function.
> Rather, mmap(), read() and write() all receive the ext2 inode of the file,
> so that all pages in memory are owned by the ext2 inode, and your inode is
> merely an indirect handle that validates the cache.  How's that sound?

Right now, an Arla inode has some extra information, containing a
dentry for the cache file. The readpage() function just validates the
cache information, fills in a struct file (with the ext2 inode) and
calls ext2's readpage(). The struct page pointer is passed along to
ext2's readpage() without any modifications.

The write() does pretty much the same thing, just that here the data
is passed via a pointer and a length.

I don't really know what's supposed to happen during a readpage()
call, and what I want is a way to make write() affect the pages that
readpage() has read.

(I might sound somewhat disoriented, but that is because I am)

If you want to have a look at the particular source, the relevant file
is http://www.stacken.kth.se/~map/src/cvs/arla/xfs/linux/xfs_inodeops.c
(xfs_readpage() and xfs_write_file()).

/Magnus
--
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: MM question

[Benjamin C.R. LaHaise]

On 22 Feb 1999, Magnus Ahltorp wrote:

> Right now, an Arla inode has some extra information, containing a
> dentry for the cache file. The readpage() function just validates the
> cache information, fills in a struct file (with the ext2 inode) and
> calls ext2's readpage(). The struct page pointer is passed along to
> ext2's readpage() without any modifications.

Okay, you probably don't want to implement readpage, just read and write,
so your read will look like:

my_read(...)
{
	validate_cache();
	return cache_inode->read(cache_inode, ...)
}

The write operation should be something like:

my_write(...)
{
	validate_cache_for_write();
	down(&cache_inode->i_sem);
	cache_inode->write(cache_inode, ...)
	up(&cache_inode->i_sem);
}

This will make your inodes relatively lightweight, and avoid having in
memory pages attached to your inode which would be duplicates of those
attached to the ext2 inode.

> I don't really know what's supposed to happen during a readpage()
> call, and what I want is a way to make write() affect the pages that
> readpage() has read.

Readpage is called by generic_file_read and page fault handlers to pull
the page into the page cache.  In the case of writing, you need to update
the page cache, as well as commit the write to whatever backstore is used. 
Since you've got the entire file cached (right?), just making use of the
ext2 inode's read & write will keep the cache coherent and reduce the
amount work you need to do. 

> (I might sound somewhat disoriented, but that is because I am)

You're asking questions, so the hard part is over =)

		-ben

--
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: MM question

[Magnus Ahltorp]

> Okay, you probably don't want to implement readpage, just read and write,
> so your read will look like:
> 
> This will make your inodes relatively lightweight, and avoid having in
> memory pages attached to your inode which would be duplicates of those
> attached to the ext2 inode.

Doesn't this mean that the read functions will be called every time
something has to be read? What about mmap?

> Readpage is called by generic_file_read and page fault handlers to pull
> the page into the page cache.  In the case of writing, you need to update
> the page cache, as well as commit the write to whatever backstore is used. 
> Since you've got the entire file cached (right?), just making use of the
> ext2 inode's read & write will keep the cache coherent and reduce the
> amount work you need to do. 

At the moment, we do whole file caching, but that might change in the
future.

/Magnus
--
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: MM question

[Stephen C. Tweedie]

Hi,

On 22 Feb 1999 22:13:09 +0100, Magnus Ahltorp <map@stacken.kth.se> said:

> Right now, an Arla inode has some extra information, containing a
> dentry for the cache file. The readpage() function just validates the
> cache information, fills in a struct file (with the ext2 inode) and
> calls ext2's readpage(). The struct page pointer is passed along to
> ext2's readpage() without any modifications.

This sounds like the source of the problem: the Arla inode's readpage
function will not be called if the page cache for the Arla page is
already present.  If you write to the underlying file, it will update
any ext2fs page cache present for the page, but will not touch the Arla
page itself.  You need to call update_vm_cache() against the appropriate
Arla inode for that to happen.  (Ext2 will already call
update_vm_cache() for the ext2fs inode, so the ext2 page cache will
remain consistent internally.)

Of course, you really want to take a step back at this point and work
out if this is really the best way forward, since you just end up
caching things twice if you are not careful...

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

mm question

[volodya]

 Things change. In particular Linux since 2.x.x. After spending several
hours peering at prolifiration of functions and constants in mm.h I
decided to take an easy way out and ask people responsible for this
sophistication:

 How does one do the following task: obtain a bunch of free pages (around
300K) with physical addresses between certain bounds (more then
0x4000000, but it is likely this is not constant) reserver them and map to
kernel space so that the driver can access them directly ?

                        thanks !

                               Vladimir Dergachev

Re: mm question

[Alan Cox]

>  How does one do the following task: obtain a bunch of free pages (around
> 300K) with physical addresses between certain bounds (more then
> 0x4000000, but it is likely this is not constant) reserver them and map to
> kernel space so that the driver can access them directly ?

We support allocating pages below 16Mb, below 4Gb, or anywhere within RAM
on x86. If you want to within a range or your 300K must be a single 300K
block then you need to allocate it at boot time

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> >  How does one do the following task: obtain a bunch of free pages (around
> > 300K) with physical addresses between certain bounds (more then
> > 0x4000000, but it is likely this is not constant) reserver them and map to
> > kernel space so that the driver can access them directly ?
> 
> We support allocating pages below 16Mb, below 4Gb, or anywhere within RAM
> on x86. If you want to within a range or your 300K must be a single 300K
> block then you need to allocate it at boot time
> 

It does not have to be contiguous. I was thinking of simply starting with 
the smallest address and trying to free the pages until the needed amount 
is available. But I have no idea how to properly do locking or force the
page to be swapped out or something. 

As for doing this during boot time this does not seem like a good idea for
two reasons: 
  a) I need at least _two_ buffers 300K each
  b) the actual amount of RAM needed changes depending on video standard
     (this is for video capture).

                     thanks

                            Vladimir Dergachev

Re: mm question

[Alan Cox]

> It does not have to be contiguous. I was thinking of simply starting with 
> the smallest address and trying to free the pages until the needed amount 
> is available. But I have no idea how to properly do locking or force the
> page to be swapped out or something. 

You can simply get_free_page() 300K of pages. However you can't land them
in a given band other than the existing "below 16Mb" "below 4Gb" "anywhere"
bands.

Alan

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > It does not have to be contiguous. I was thinking of simply starting with 
> > the smallest address and trying to free the pages until the needed amount 
> > is available. But I have no idea how to properly do locking or force the
> > page to be swapped out or something. 
> 
> You can simply get_free_page() 300K of pages. However you can't land them
> in a given band other than the existing "below 16Mb" "below 4Gb" "anywhere"
> bands.

Right, but then my card refuses to dma into anything with address smaller
than 04000000.

I have thought of doing get_free_page until I have enough of pages with
large addresses (and then free all the small ones as 64mb is a finite
amount) but this would place a big load on the system during buffer
allocation.

I was hoping for something more elegant, but I am not adverse to writing
my own get_free_page_from_range().

                            Vladimir Dergachev

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

Re: mm question

[Alan Cox]

> Right, but then my card refuses to dma into anything with address smaller
> than 04000000.

What was your board designer on when they decided to bar DMA below 64Mb ?

> amount) but this would place a big load on the system during buffer
> allocation.

And might never terminate

> I was hoping for something more elegant, but I am not adverse to writing
> my own get_free_page_from_range().

Thats not a trivial task.

Re: mm question

[Rik van Riel]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > I was hoping for something more elegant, but I am not adverse to writing
> > my own get_free_page_from_range().
>
> Thats not a trivial task.

Especially because we never quite know the users of a
physical page, so moving data around is somewhat hard.

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > Right, but then my card refuses to dma into anything with address smaller
> > than 04000000.
> 
> What was your board designer on when they decided to bar DMA below 64Mb ?

Not mine (unfortunately ?). The card in question is ATI All-in-Wonder
Radeon - and I am trying to get video capture working. Unfortunately the
documentation is quite terse - for example the dma table register
description mentions its width, offset and "No description is provided".

Additionally I have to tiptoe my way around DRI driver which also uses
busmastering.

At the moment I have a working driver with one bug: DMA transfer just does
not happen into pages with address less than 0x4000000 which is the same
value as physical address of the ring buffer.

I suspect that this is somehow connected with the amount of available 
"AGP addressable" memory which is ~64meg less than the total amount on my
machine. However, looking around in AGP driver or AGP specs does not seem
to indicate any restriction of the sort and, moreover, I do not need AGP
for this DMA transfer (it is PCI only).

> 
> > amount) but this would place a big load on the system during buffer
> > allocation.
> 
> And might never terminate

I thought of establishing a timeout and giving up after a while. The
buffer is allocated once for each open on /dev/videoX so it is not too
critical - though I would not want to cause and OOM condition.

> 
> > I was hoping for something more elegant, but I am not adverse to writing
> > my own get_free_page_from_range().
> 
> Thats not a trivial task.
> 

Better than giving up.. Unfortunately looking around in
linux/Documentation and drivers did not yield much in terms of
explanation. I know I can use mem_map_reserve to reserve a page but I
don't know how to get page struct from a physical address nor which lock
to use when messing with this.

                     thanks

                         Vladimir Dergachev

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Rik van Riel wrote:

> On Mon, 10 Dec 2001, Alan Cox wrote:
> 
> > > I was hoping for something more elegant, but I am not adverse to writing
> > > my own get_free_page_from_range().
> >
> > Thats not a trivial task.
> 
> Especially because we never quite know the users of a
> physical page, so moving data around is somewhat hard.

I don't want to move them - I just want to collect all that are free and
then try to free some more. 

                            Vladimir Dergachev

> 
> cheers,
> 
> Rik
> -- 
> DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> -
> 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/
> 

Re: mm question

[Rik van Riel]

On Mon, 10 Dec 2001 volodya@mindspring.com wrote:
> On Mon, 10 Dec 2001, Rik van Riel wrote:
> > On Mon, 10 Dec 2001, Alan Cox wrote:
> >
> > > > I was hoping for something more elegant, but I am not adverse to writing
> > > > my own get_free_page_from_range().
> > >
> > > Thats not a trivial task.
> >
> > Especially because we never quite know the users of a
> > physical page, so moving data around is somewhat hard.
>
> I don't want to move them - I just want to collect all that are free
> and then try to free some more.

I could put it on the TODO list for my VM stuff, but it's
not exactly near the top of the list so it might take quite
a while more before I get around to this...

http://linuxvm.bkbits.net/

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Rik van Riel wrote:

> On Mon, 10 Dec 2001 volodya@mindspring.com wrote:
> > On Mon, 10 Dec 2001, Rik van Riel wrote:
> > > On Mon, 10 Dec 2001, Alan Cox wrote:
> > >
> > > > > I was hoping for something more elegant, but I am not adverse to writing
> > > > > my own get_free_page_from_range().
> > > >
> > > > Thats not a trivial task.
> > >
> > > Especially because we never quite know the users of a
> > > physical page, so moving data around is somewhat hard.
> >
> > I don't want to move them - I just want to collect all that are free
> > and then try to free some more.
> 
> I could put it on the TODO list for my VM stuff, but it's
> not exactly near the top of the list so it might take quite
> a while more before I get around to this...

Thanks, but I was more hoping for the advice on how I can make it myself.. 
the same way as bt848 driver has its own memory allocation functions.

                                      Vladimir Dergachev

> 
> http://linuxvm.bkbits.net/
> 
> cheers,
> 
> Rik
> -- 
> DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 

Re: mm question

[Martin J. Bligh]

>> > I was hoping for something more elegant, but I am not adverse to writing
>> > my own get_free_page_from_range().
>> 
>> Thats not a trivial task.
> 
> Better than giving up.. Unfortunately looking around in
> linux/Documentation and drivers did not yield much in terms of
> explanation. I know I can use mem_map_reserve to reserve a page but I
> don't know how to get page struct from a physical address nor which lock
> to use when messing with this.

If you don't have any ISA DMA going on in the system, you might consider
bastardising the ZONE_DMA page range by moving the boundary up to
64Mb, then fixing the allocator not to fail back ZONE_NORMAL et al 
allocations to ZONE_DMA. Thus what was originally ZONE_DMA becomes 
a sort of ZONE_NO_DMA. Not in the slightest bit pretty, but it might be easier 
to implement. Depends if you ever want it to get back into the main tree,
I guess ;-)

M.

Re: mm question

[Alan Cox]

> I don't want to move them - I just want to collect all that are free and
> then try to free some more. 

How will you free them, you don't know who owns them. 

Re: mm question

[Martin J. Bligh]

>>> > I was hoping for something more elegant, but I am not adverse to writing
>>> > my own get_free_page_from_range().
>>> 
>>> Thats not a trivial task.
>> 
>> Better than giving up.. Unfortunately looking around in
>> linux/Documentation and drivers did not yield much in terms of
>> explanation. I know I can use mem_map_reserve to reserve a page but I
>> don't know how to get page struct from a physical address nor which lock
>> to use when messing with this.
> 
> If you don't have any ISA DMA going on in the system, you might consider
> bastardising the ZONE_DMA page range by moving the boundary up to
> 64Mb, then fixing the allocator not to fail back ZONE_NORMAL et al 
> allocations to ZONE_DMA. Thus what was originally ZONE_DMA becomes 
> a sort of ZONE_NO_DMA. Not in the slightest bit pretty, but it might be easier 
> to implement. Depends if you ever want it to get back into the main tree,
> I guess ;-)

Of course, if you just did that, you'd never use the ZONE_DMA memory, so
that's pretty pointless ;-) You need to create an alloc call with an *option* 
to force alloc out of ZONE_NORMAL, not make no fallback the default. 

M.

Re: mm question

[Alan Cox]

> "AGP addressable" memory which is ~64meg less than the total amount on my
> machine. However, looking around in AGP driver or AGP specs does not seem
> to indicate any restriction of the sort and, moreover, I do not need AGP
> for this DMA transfer (it is PCI only).

Can the transfer go to pages mapped into the AGP gart, using their gart
side mapping ?

> Better than giving up.. Unfortunately looking around in
> linux/Documentation and drivers did not yield much in terms of
> explanation. I know I can use mem_map_reserve to reserve a page but I
> don't know how to get page struct from a physical address nor which lock
> to use when messing with this.

You have to grab them at boot time via bootmem to get them in a range of
your choice. Otherwise you can use

	get_free_page		-	grab a page
	virt_to_page		-	page struct of page
	virt_to_bus		-	bus addr of page

virt_to_bus isnt portable because real world pci bus mapping on non x86 is
deeply murky and mysterious. But you probably want to worry about that
after it works.

Alan

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Martin J. Bligh wrote:

> >> > I was hoping for something more elegant, but I am not adverse to writing
> >> > my own get_free_page_from_range().
> >> 
> >> Thats not a trivial task.
> > 
> > Better than giving up.. Unfortunately looking around in
> > linux/Documentation and drivers did not yield much in terms of
> > explanation. I know I can use mem_map_reserve to reserve a page but I
> > don't know how to get page struct from a physical address nor which lock
> > to use when messing with this.
> 
> If you don't have any ISA DMA going on in the system, you might consider
> bastardising the ZONE_DMA page range by moving the boundary up to
> 64Mb, then fixing the allocator not to fail back ZONE_NORMAL et al 
> allocations to ZONE_DMA. Thus what was originally ZONE_DMA becomes 
> a sort of ZONE_NO_DMA. Not in the slightest bit pretty, but it might be easier 
> to implement. Depends if you ever want it to get back into the main tree,
> I guess ;-)

Won't work - this is for general public..

                         Vladimir Dergachev

> 
> M.
> 

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > I don't want to move them - I just want to collect all that are free and
> > then try to free some more. 
> 
> How will you free them, you don't know who owns them. 

I think you misunderstood me - this allocation happens in response to the
system call _not_ in an interrupt handler. So it is ok to wait - as long
as needed. I was thinking of calling page swapper or something and perhaps
going after I/O buffers first. 

                               Vladimir Dergachev

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

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > "AGP addressable" memory which is ~64meg less than the total amount on my
> > machine. However, looking around in AGP driver or AGP specs does not seem
> > to indicate any restriction of the sort and, moreover, I do not need AGP
> > for this DMA transfer (it is PCI only).
> 
> Can the transfer go to pages mapped into the AGP gart, using their gart
> side mapping ?

Yes, but agpgart will not let more then one driver use it. So it will be
_either_ 3d or video capture with switching upon Xserver restart. Sucks !

> 
> > Better than giving up.. Unfortunately looking around in
> > linux/Documentation and drivers did not yield much in terms of
> > explanation. I know I can use mem_map_reserve to reserve a page but I
> > don't know how to get page struct from a physical address nor which lock
> > to use when messing with this.
> 
> You have to grab them at boot time via bootmem to get them in a range of

Does this imply that the driver must be compiled into the kernel ? In that
case I'll need to allocate at least 2meg of ram for each capture card..

> your choice. Otherwise you can use
> 
> 	get_free_page		-	grab a page
> 	virt_to_page		-	page struct of page
> 	virt_to_bus		-	bus addr of page
> 
> virt_to_bus isnt portable because real world pci bus mapping on non x86 is
> deeply murky and mysterious. But you probably want to worry about that
> after it works.

Yes, I almost went all the way rewriting the code in accordance with
DMA-mapping.txt thinking I am using "non-DMAable" memory or something 
until I noticed that all the functions are inlined to trivial for x86.

                           Vladimir Dergachev

> 
> Alan
> 

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > Yes, but agpgart will not let more then one driver use it. So it will be
> > _either_ 3d or video capture with switching upon Xserver restart. Sucks !
> 
> That sounds like agpgart needs fixing. Its going to be easier than hacking
> the vm code
> 

Well, I was trying to avoid that and simply distribute additional memory
management routines with the driver. 

                     Vladimir Dergachev

Re: mm question

[Alan Cox]

> Yes, but agpgart will not let more then one driver use it. So it will be
> _either_ 3d or video capture with switching upon Xserver restart. Sucks !

That sounds like agpgart needs fixing. Its going to be easier than hacking
the vm code

Re: mm question

[Rik van Riel]

On Mon, 10 Dec 2001 volodya@mindspring.com wrote:
> On Mon, 10 Dec 2001, Alan Cox wrote:
>
> > > I don't want to move them - I just want to collect all that are free and
> > > then try to free some more.
> >
> > How will you free them, you don't know who owns them.
>
> I think you misunderstood me - this allocation happens in response to
> the system call _not_ in an interrupt handler. So it is ok to wait -
> as long as needed. I was thinking of calling page swapper or something
> and perhaps going after I/O buffers first.

Even if you have a handle on a physical page, you don't know
what processes are using the page, nor if there are additional
users besides the processes.

This makes it rather hard to go around trying to free pages
within a certain physical range.

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Rik van Riel wrote:

> On Mon, 10 Dec 2001 volodya@mindspring.com wrote:
> > On Mon, 10 Dec 2001, Alan Cox wrote:
> >
> > > > I don't want to move them - I just want to collect all that are free and
> > > > then try to free some more.
> > >
> > > How will you free them, you don't know who owns them.
> >
> > I think you misunderstood me - this allocation happens in response to
> > the system call _not_ in an interrupt handler. So it is ok to wait -
> > as long as needed. I was thinking of calling page swapper or something
> > and perhaps going after I/O buffers first.
> 
> Even if you have a handle on a physical page, you don't know
> what processes are using the page, nor if there are additional
> users besides the processes.
> 
> This makes it rather hard to go around trying to free pages
> within a certain physical range.

Well, what does kernel do when it runs out of memory ? For example when I
mmap a large file and start reading it back and force ?

                                   Vladimir Dergachev

> 
> cheers,
> 
> Rik
> -- 
> DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 

Re: mm question

[Alan Cox]

> > That sounds like agpgart needs fixing. Its going to be easier than hacking
> > the vm code
> 
> Well, I was trying to avoid that and simply distribute additional memory
> management routines with the driver. 

Thats going to be a no go. To create a new memory zone as  you need means
mucking around in the very depths of the mm code in the kernel core.

Re: mm question

[Rik van Riel]

On Mon, 10 Dec 2001 volodya@mindspring.com wrote:
> On Mon, 10 Dec 2001, Rik van Riel wrote:

> > Even if you have a handle on a physical page, you don't know
> > what processes are using the page, nor if there are additional
> > users besides the processes.
>
> Well, what does kernel do when it runs out of memory ? For example
> when I mmap a large file and start reading it back and force ?

For the full horror, see mm/vmscan.c, do_try_to_free_memory()

cheers,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: mm question

[Alan Cox]

> > This makes it rather hard to go around trying to free pages
> > within a certain physical range.
> 
> Well, what does kernel do when it runs out of memory ? For example when I
> mmap a large file and start reading it back and force ?

It doesn't care which physical page it gets. Processes being freeing
up/swapping pages they have mappings to. The map counts hit zero and the 
page is discarded.

Alan

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > > This makes it rather hard to go around trying to free pages
> > > within a certain physical range.
> > 
> > Well, what does kernel do when it runs out of memory ? For example when I
> > mmap a large file and start reading it back and force ?
> 
> It doesn't care which physical page it gets. Processes being freeing
> up/swapping pages they have mappings to. The map counts hit zero and the 
> page is discarded.

Right, but instead of trying to balance cache available memory and swap
my swapper will only be concerned whether the page can be evicted and
whether it is from the address range I want.

The scheme is like:

  open -> request buffer allocation -> start region_swapper  ->
     -> wait for freed memory to accumulate and reserve as it appears -> 
     -> when enough is available stop swapper and declare allocation finished

                                Vladimir Dergachev

> 
> Alan
> 

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Rik van Riel wrote:

> On Mon, 10 Dec 2001 volodya@mindspring.com wrote:
> > On Mon, 10 Dec 2001, Rik van Riel wrote:
> 
> > > Even if you have a handle on a physical page, you don't know
> > > what processes are using the page, nor if there are additional
> > > users besides the processes.
> >
> > Well, what does kernel do when it runs out of memory ? For example
> > when I mmap a large file and start reading it back and force ?
> 
> For the full horror, see mm/vmscan.c, do_try_to_free_memory()

Wonderful !This is the kind of advice I was looking for :))

So if I copy it over to, say, do_try_to_free_region_memory1() and start
hacking - will this violate some grand scheme of kernel development ?
I.e. is there anything inherently wrong with two different kswapd going on ?

                   thanks !

                          Vladimir Dergachev

> 
> cheers,
> 
> Rik
> -- 
> DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 

Re: mm question

[Alan Cox]

> Right, but instead of trying to balance cache available memory and swap
> my swapper will only be concerned whether the page can be evicted and
> whether it is from the address range I want.

You want to rewrite the entire vm to have back pointers ? Right now you
can't find pages in an address range. Its all driven from the virtual side
without reverse lookup tables.

Re: mm question

[volodya]

On Mon, 10 Dec 2001, Alan Cox wrote:

> > Right, but instead of trying to balance cache available memory and swap
> > my swapper will only be concerned whether the page can be evicted and
> > whether it is from the address range I want.
> 
> You want to rewrite the entire vm to have back pointers ? Right now you
> can't find pages in an address range. Its all driven from the virtual side
> without reverse lookup tables.
> 

You are right I don't want to rewrite vm. But I can go thru virtual side
taking note of the physical address. I.e. base the decision to try and
free pages not on how old the page is but on what it's physical address
is.

You see, I don't want to find a few pages in 16mb range in 512mb system.

I want to find a few pages _outside_ 64mb range in a 512mb system. 
So if I free 70mb I _will_ be able to find at least 2mb in my desired
range. In fact I won't have to free that much as they it will work is
"try to free the page", "if succeed do not return to memory pool but
instead give to the 'special region list'"

Does this make sense ?

                         Vladimir Dergachev

Re: mm question

[Eric W. Biederman]

volodya@mindspring.com writes:

> On Mon, 10 Dec 2001, Alan Cox wrote:
> 
> > > Right, but instead of trying to balance cache available memory and swap
> > > my swapper will only be concerned whether the page can be evicted and
> > > whether it is from the address range I want.
> > 
> > You want to rewrite the entire vm to have back pointers ? Right now you
> > can't find pages in an address range. Its all driven from the virtual side
> > without reverse lookup tables.
> > 
> 
> You are right I don't want to rewrite vm. But I can go thru virtual side
> taking note of the physical address. I.e. base the decision to try and
> free pages not on how old the page is but on what it's physical address
> is.
> 
> You see, I don't want to find a few pages in 16mb range in 512mb system.
> 
> I want to find a few pages _outside_ 64mb range in a 512mb system. 
> So if I free 70mb I _will_ be able to find at least 2mb in my desired
> range. In fact I won't have to free that much as they it will work is
> "try to free the page", "if succeed do not return to memory pool but
> instead give to the 'special region list'"
> 
> Does this make sense ?

There is actually a cheap trick that will achieve what you want.
Allocate pages.  If you allocate a page in the 0-64mb range keep
it allocated until you have allocated your 300KB > 64mb.  After
you have all of the pages you want free the extra pages in 0-64mb that
you didn't want...

Eric

Re: mm question

[volodya]

On 11 Dec 2001, Eric W. Biederman wrote:

> volodya@mindspring.com writes:
> 
> > On Mon, 10 Dec 2001, Alan Cox wrote:
> > 
> > > > Right, but instead of trying to balance cache available memory and swap
> > > > my swapper will only be concerned whether the page can be evicted and
> > > > whether it is from the address range I want.
> > > 
> > > You want to rewrite the entire vm to have back pointers ? Right now you
> > > can't find pages in an address range. Its all driven from the virtual side
> > > without reverse lookup tables.
> > > 
> > 
> > You are right I don't want to rewrite vm. But I can go thru virtual side
> > taking note of the physical address. I.e. base the decision to try and
> > free pages not on how old the page is but on what it's physical address
> > is.
> > 
> > You see, I don't want to find a few pages in 16mb range in 512mb system.
> > 
> > I want to find a few pages _outside_ 64mb range in a 512mb system. 
> > So if I free 70mb I _will_ be able to find at least 2mb in my desired
> > range. In fact I won't have to free that much as they it will work is
> > "try to free the page", "if succeed do not return to memory pool but
> > instead give to the 'special region list'"
> > 
> > Does this make sense ?
> 
> There is actually a cheap trick that will achieve what you want.
> Allocate pages.  If you allocate a page in the 0-64mb range keep
> it allocated until you have allocated your 300KB > 64mb.  After
> you have all of the pages you want free the extra pages in 0-64mb that
> you didn't want...

Yes, I thought of that, but this might produce more memory pressure than
needed. 

Regardless, it looks like I won't need this after all - the device has
internal memory controller which was misprogrammed. I think I corrected
this so it looks to be working now.

However, the question of how to get pages from a given range is
interesting in itself..

                 big thanks to everyone who responded :))

                            Vladimir Dergachev

> 
> Eric
> 

Re: mm question

[Daniel Phillips]

On December 11, 2001 12:07 pm, volodya@mindspring.com wrote:
> On 11 Dec 2001, Eric W. Biederman wrote:
> > There is actually a cheap trick that will achieve what you want.
> > Allocate pages.  If you allocate a page in the 0-64mb range keep
> > it allocated until you have allocated your 300KB > 64mb.  After
> > you have all of the pages you want free the extra pages in 0-64mb that
> > you didn't want...
> 
> Yes, I thought of that, but this might produce more memory pressure than
> needed. 
> 
> Regardless, it looks like I won't need this after all - the device has
> internal memory controller which was misprogrammed. I think I corrected
> this so it looks to be working now.
> 
> However, the question of how to get pages from a given range is
> interesting in itself..

Yes, particularly numa folks.

--
Daniel