RE: [PATCH 8/9] dspbridge: add map support for big buffers
From: Guzman Lugo, Fernando
Date: Tue Aug 24 2010 - 15:30:40 EST
> -----Original Message-----
> From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx]
> Sent: Tuesday, August 24, 2010 2:14 PM
> To: Guzman Lugo, Fernando
> Cc: Kanigeri, Hari; linux-omap@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; ohad@xxxxxxxxxx;
> hiroshi.doyu@xxxxxxxxx; ameya.palande@xxxxxxxxx;
> felipe.contreras@xxxxxxxxx
> Subject: Re: [PATCH 8/9] dspbridge: add map support for big buffers
>
> On Tue, Aug 24, 2010 at 10:05 PM, Guzman Lugo, Fernando
> <fernando.lugo@xxxxxx> wrote:
> >> I've heard there are some problems regarding DMM, and
> since you say
> >> you have already done the changes, and since iommu
> migration is not
> >> yet ready AFAIK, it might make sense to go for option b).
> >>
> >> Anyway, thanks for the clarification :)
> >
> > But DMM is used in this momment, it is after the IOMMU
> migration When
> > DMM is not needed anymore. So we need to go for option a).
>
> Oh, I actually meant the DMM pool.
>
> a) 1. Migrate to iommu, 2. Remove DMM completely
> b) 1. Remove DMM pool, 2. Migrate to iommu 3. Remove DMM completely
Ok, what is the issue with DMM pool?
The issue I see removing DMM pool in this moment and making all the DMM
Available (from 0x11000000 to 0xFFFFFFFF omap3 case) that is:
The DMM module allocates a list of "struct map_page" elements base on
DMM_POOL_SIZE to keep track of memory reserved and mapped.
Memory allocated = DMM_POOL_SIZE / PAGE_SIZE * sizeof(struct map_page);
So making all memory avalible it will increase the memory used for DMM
Module and it could be quite significant.
Iovmm.c module, the list is increased dynamically when it is needed so
It does no have that problem. Then when the migration is done and
Iovmm.c module is used the DMM_POOL_SIZE can be removed without issues.
Regards,
Fernando.
>
> --
> Felipe Contreras
> --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/