RE: [PATCH 0/3] hwmem: Hardware memory driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
ÿô.nlj·ÿ±ég¬±¨Âaþé»®&Þ)î¦þ)íèh™¨è&£ù¢¸ÿŠæ¢ú»þÇþm§ÿÿÃÿ–)î¦þŠàb‚nö¥yʦ‰bs(§	©Ú¯ìáÿÿ÷%½ëÊs÷'þ×j)ÿým£ÿÝ{ÿ’ö+ƒÿÞ¨¥þKÚOèÿ



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]