Implications of PG_locked and reference count in page structures....

Implications of PG_locked and reference count in page structures....

[Michael Heinz]

I'm in the process of porting a driver to Linux. The author of the 
driver conveniently broke it into os-dependent and independent sections.

One of the things in the "OS" dependent section is a routine to lock a 
section of memory presumably to be used for DMA.

So, what I want to do is this: given a pointer to a previously 
kmalloc'ed block, and the length of that block, I want to (a) identify 
each page associated with the block and (b) lock each page. It appears 
that I can lock the page either by incrementing it's reference count, or 
by setting the PG_locked flag for the page.

Which method is preferred? Is there another method I should be using 
instead?

Re: Implications of PG_locked and reference count in page structures....

[Ignacio Vazquez-Abrams]

On Wed, 15 Aug 2001, Michael Heinz wrote:

> I'm in the process of porting a driver to Linux. The author of the
> driver conveniently broke it into os-dependent and independent sections.
>
> One of the things in the "OS" dependent section is a routine to lock a
> section of memory presumably to be used for DMA.
>
> So, what I want to do is this: given a pointer to a previously
> kmalloc'ed block, and the length of that block, I want to (a) identify
> each page associated with the block and (b) lock each page. It appears
> that I can lock the page either by incrementing it's reference count, or
> by setting the PG_locked flag for the page.
>
> Which method is preferred? Is there another method I should be using
> instead?

Linux has seperate functionality for DMA transfers so you don't neccesarily
have to do all that. If you're _certain_ that the memory is going to be used
for DMA, then have a look at http://www.xml.com/ldd/chapter/book/ch13.html and
scroll down to the part that talks about DMA. In fact, if you're fairly new to
Linux drivers then I would suggest that you take a look at
http://www.xml.com/ldd/chapter/book/index.html.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: Implications of PG_locked and reference count in page structures....

[Daniel Phillips]

On August 15, 2001 05:39 pm, Michael Heinz wrote:
> I'm in the process of porting a driver to Linux. The author of the 
> driver conveniently broke it into os-dependent and independent sections.
> 
> One of the things in the "OS" dependent section is a routine to lock a 
> section of memory presumably to be used for DMA.
> 
> So, what I want to do is this: given a pointer to a previously 
> kmalloc'ed block, and the length of that block, I want to (a) identify 
> each page associated with the block and (b) lock each page. It appears 
> that I can lock the page either by incrementing it's reference count, or 
> by setting the PG_locked flag for the page.
> 
> Which method is preferred? Is there another method I should be using 
> instead?

See the other replies - you do not need to memlock your pages because you
will be allocating non-pageable kernel memory.

But for future reference, PG_locked is for serializing IO/cache
operations.  You use the page reference count to prevent a page from
being freed, i.e., to memlock it.  You'll see such object ref-counting
schemes showing up all through the kernel in slight variations.

--
Daniel

RE: Implications of PG_locked and reference count in page structures....

[Heinz, Michael]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

Thanks for all the replies; 

I am using the O'Reilly book - but I'm kind of stuck using the semantics
that the driver's original author used. The whole effort is so we can
experiment with some hardware rather than for final release, so we don't
want to spend too much effort reengineering anything we don't have to.

Heh. I missed the part in LDD that mentions kmalloc regions being
unpageable. 

;->

--
"Oh, bother!" said the Borg. "We've assimilated Pooh!"
"Thanks for noticing." replied Eeyore.

mheinz@infiniconsys.com
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Heinz, Michael.vcf --]
[-- Type: text/x-vcard; name="Heinz, Michael.vcf", Size: 140 bytes --]

BEGIN:VCARD
VERSION:2.1
N:Heinz;Michael
FN:Heinz, Michael
EMAIL;PREF;INTERNET:mheinz@infiniconsys.com
REV:20010711T191535Z
END:VCARD

Re: Implications of PG_locked and reference count in page structures....

[Alan Cox]

> So, what I want to do is this: given a pointer to a previously 
> kmalloc'ed block, and the length of that block, I want to (a) identify 
> each page associated with the block and (b) lock each page. It appears 
> that I can lock the page either by incrementing it's reference count, or 
> by setting the PG_locked flag for the page.

If the block was allocated with kmalloc it isnt pageable. That means all you
need to do is to use the virt_to_bus() call. If you are doing PCI DMA
however the preferred approach from 2.4 onwards is the pci_alloc_* API
(see Documentation/DMA-mapping.txt)

> Which method is preferred? Is there another method I should be using 
> instead?

You should be fine. If they were user pages then you would want to look
at the kiovec support for mapping user pages and locking them down. For
kernel allocated buffers it is nice and easy.

The only other oddment to note is that ISA bus DMA requires GFP_DMA as a 
kmalloc flag, PCI DMA does not (GFP_DMA is "below 16Mb please")

Alan