linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johan MOSSBERG <johan.xx.mossberg@stericsson.com>
To: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: RE: [PATCH 0/3] hwmem: Hardware memory driver
Date: Fri, 19 Nov 2010 14:47:02 +0100	[thread overview]
Message-ID: <C832F8F5D375BD43BFA11E82E0FE9FE0081BEE26FD@EXDCVYMBSTM005.EQ1STM.local> (raw)
In-Reply-To: <op.vmeyr3fd7p4s8u@pikus>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2115 bytes --]

Michał Nazarewicz wrote:
> >> Do you want to remap user space mappings when page is moved during
> >> defragmentation? Or would user need to unmap the region?  Ie. would
> >> mmap()ed buffer be pinned?
> >
> > Remap, i.e. not pinned. That means that the mapper needs to be
> > informed before and after a buffer is moved. Maybe add a function
> > to CMA where you can register a callback function that is called
> > before and after a buffer is moved? The callback function's
> > parameters would be buffer, new position and whether it will be
> > moved or has been moved. CMA would also need this type of
> > information to be able to evict temporary data from the
> > destination.
> 
> The way I imagine pinning is that the allocator tells CMA that it want
> to use given region of memory.  This would make CMA remove any kind of
> data that is stored there (in the version of CMA I'm about to post that
> basically means migrating pages).

I don't understand what you mean with "pinning" but yes when the
allocator moves a buffer it will have to inform CMA both what
memory it will use (so that it can be evicted) and what memory it
will no longer use (so that it can be used for other stuff).

> I think the question at this moment is whether we need such a mechanism
> to be implemented at the this time.  I would rather wait with the
> callback mechanism till the rest of the framework works and we have
> an algorithm that actually does the defragmentation.

I agree. So long as we know it can be added without too much
trouble in the future that'll be fine. I actually think the "making
good use of the free memory in regions" feature is more important
than defragmentation. The reason I wanted a discussion about
defragmentation was to make sure the door wasn't closed on adding
support for defragmentation in the future and to make sure it is
taken into consideration when designing and implementing CMA.

/Johan Mossberg
N‹§²æìr¸›zǧu©ž²Æ {\b­†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨­è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒñb‚^[nö¢®×¥yÊ&¦‰bs(§	©Úu«"‚xm¶Ÿÿv+,¢[Þ¶\x17œ®×\x1ckðèž×¦j)Z†·Ÿ

      reply	other threads:[~2010-11-19 13:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-16 13:07 Johan Mossberg
2010-11-16 13:08 ` [PATCH 1/3] hwmem: Add hwmem (part 1) Johan Mossberg
2010-11-16 13:08   ` [PATCH 2/3] hwmem: Add hwmem (part 2) Johan Mossberg
2010-11-16 13:08     ` [PATCH 3/3] hwmem: Add hwmem to ux500 and mop500 Johan Mossberg
2010-11-16 14:50 ` [PATCH 0/3] hwmem: Hardware memory driver Michał Nazarewicz
2010-11-16 15:25   ` Johan MOSSBERG
2010-11-16 15:33     ` Michał Nazarewicz
2010-11-16 16:16       ` Johan MOSSBERG
2010-11-16 17:36         ` Michał Nazarewicz
2010-11-17  9:28           ` Johan MOSSBERG
2010-11-19 10:44             ` Michał Nazarewicz
2010-11-19 13:47               ` Johan MOSSBERG [this message]

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=C832F8F5D375BD43BFA11E82E0FE9FE0081BEE26FD@EXDCVYMBSTM005.EQ1STM.local \
    --to=johan.xx.mossberg@stericsson.com \
    --cc=linux-mm@kvack.org \
    --cc=m.nazarewicz@samsung.com \
    /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