linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Jaya Kumar" <jayakumar.lkml@gmail.com>
To: linux-mm@kvack.org
Subject: Deleting PTEs for deferred IO for framebuffers
Date: Sat, 9 Dec 2006 07:53:33 -0500	[thread overview]
Message-ID: <45a44e480612090453j5fe92b9cx23fb2c28ad5f57@mail.gmail.com> (raw)

Hi,

I'm experimenting with trying to do some deferred IO for framebuffers.
This is associated with trying to support the hecubafb/E-Ink driver.
http://marc.theaimsgroup.com/?l=linux-fbdev-devel&m=116357495806415&w=2
The usage scenario is like this:
- userspace app mmaps framebuffer
- driver handles and sets up a nopage handler
- app tries to write to mmaped vaddress
- get pagefault and reaches driver's nopage handler
- driver's nopage handler saves vma and vaddress, finds and returns
physical page ( not actual framebuffer )
- also schedules a workqueue task
- app continues writing to that page
- the workqueue task comes in and unmaps the page, then completes the
slow work associated with updating the framebuffer
- app tries to write to the previously mapped address (that has now
been unmapped)
- get pagefault and the above sequence occurs again
The desire is to allow bursty framebuffer updates to all occur. Then
when things are quiet, we go and update the framebuffer. This is
helpful for specific types of framebuffers and possibly other devices
where only the final result in memory is desired and IO is slow or
expensive in terms of power usage or both.

My question in trying to implement above is how to delete pte-s. Is
there a recommended way to delete a pte from code outside linux/mm? I
have the app's vma and the vaddress from when it initially faults
through a nopage. I think i could do work similar to
remove_migration_pte(). That is, spin_lock(vma->lock),
pgd/pud/pmd/pte_offset and then pte_unmap. then unlock.
I may be quite stupid so I might be missing the simple proper way to
do this. I'd appreciate any help or feedback.

Thanks,
jayakumar

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

                 reply	other threads:[~2006-12-09 12:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45a44e480612090453j5fe92b9cx23fb2c28ad5f57@mail.gmail.com \
    --to=jayakumar.lkml@gmail.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox