linux-kernel - RE: [Uclinux-dist-devel] [PATCH] mm/nommu.c:Dynamic alloc/freepercpu area for nommu

Open Source and information security mailing list archives

Date:	Mon, 22 Mar 2010 12:14:50 +0800
From:	"Zhang, Sonic" <Sonic.Zhang@...log.com>
To:	"Tejun Heo" <tj@...nel.org>, <graff.yang@...il.com>
CC:	<dhowells@...hat.com>, <uclinux-dist-devel@...ckfin.uclinux.org>,
	<akpm@...ux-foundation.org>, <linux-kernel@...r.kernel.org>
Subject: RE: [Uclinux-dist-devel] [PATCH] mm/nommu.c:Dynamic alloc/freepercpu area for nommu

>-----Original Message-----
>From: uclinux-dist-devel-bounces@...ckfin.uclinux.org 
>[mailto:uclinux-dist-devel-bounces@...ckfin.uclinux.org] On 
>Behalf Of Tejun Heo
>Sent: Saturday, March 20, 2010 12:07 PM
>To: graff.yang@...il.com
>Cc: dhowells@...hat.com; 
>uclinux-dist-devel@...ckfin.uclinux.org; 
>akpm@...ux-foundation.org; linux-kernel@...r.kernel.org
>Subject: Re: [Uclinux-dist-devel] [PATCH] mm/nommu.c:Dynamic 
>alloc/freepercpu area for nommu
>
>Hello,
>
>On 03/19/2010 06:02 PM, graff.yang@...il.com wrote:
>> From: Graff Yang<graff.yang@...il.com>
>>
>> This patch supports dynamic alloc/free percpu area for nommu 
>arch like 
>> blackfin.
>> It allocates contiguous pages in funtion pcpu_get_vm_areas() instead 
>> of getting none contiguous pages then vmap it in mmu arch.
>> As we can not get the real page structure through vmalloc_to_page(), 
>> so it also modified the nommu version 
>vmalloc_to_page()/vmalloc_to_pfn().
>>
>> Signed-off-by: Graff Yang<graff.yang@...il.com>
>
>Heh heh... I've never imagined there would be a SMP 
>architecture w/o mmu.  That's pretty interesting.  I mean, 
>there is real estate for multiple cores but not for mmu?
>

Yes, the bf561 from Analog Device is an embeded dual-core CPU without
MMU. And we successfully port the SMP kernel to it with software cache
coherency support. Although it doesn't support different threads on
different core, multi processors still runs well concurrently.

>> diff --git a/mm/nommu.c b/mm/nommu.c
>> index 605ace8..98bbdf4 100644
>> --- a/mm/nommu.c
>> +++ b/mm/nommu.c
>> @@ -255,13 +255,15 @@ EXPORT_SYMBOL(vmalloc_user);
>>
>>   struct page *vmalloc_to_page(const void *addr)
>>   {
>> -	return virt_to_page(addr);
>> +	return (struct page *)
>> +			(virt_to_page(addr)->index) ? : 
>virt_to_page(addr);
>
>Nothing major but isn't it more usual to write ?: without the 
>intervening space?
>
>> +#ifdef CONFIG_SMP
>> +int map_kernel_range_noflush(unsigned long addr, unsigned long size,
>> +					pgprot_t prot, struct 
>page **pages) {
>
>More nitpicks.
>
>> +	int i, nr_page = size>>  PAGE_SHIFT;
>
>	       nr_pages = size >> PAGE_SHIFT;
>
>> +	for (i = 0; i<  nr_page; i++, addr += PAGE_SIZE)
>
>		    i < nr_pages
>
>> +		virt_to_page(addr)->index = (pgoff_t)pages[i];
>> +	return size>>  PAGE_SHIFT;
>
>	return size >> PAGE_SHIFT;
>
>I think checkpatch would whine about these too.
>
>> +void unmap_kernel_range_noflush(unsigned long addr, unsigned long 
>> +size) {
>> +	int i, nr_page = size>>  PAGE_SHIFT;
>> +	for (i = 0; i<  nr_page; i++, addr += PAGE_SIZE)
>> +		virt_to_page(addr)->index = 0;
>> +}
>> +
>> +struct vm_struct **pcpu_get_vm_areas(const unsigned long *offsets,
>> +					const size_t *sizes, int nr_vms,
>> +						size_t align, 
>gfp_t gfp_mask)
>
>Hmmm... in general, one of the reasons the percpu allocation 
>is complex is to avoid contiguous allocations while avoiding 
>additional TLB / NUMA overhead on machines with rather complex 
>memory configuration (which is pretty common these days).  If 
>the memory has to be allocated contiguous anyway, it probably 
>would be much simpler to hook at higher level and simply 
>allocate each chunk contiguously.
>I'll look into it.
>
It is more reasonable to handle the dynamic malloc of continous percpu
data for NOMMU arch in a high layer.

Sonic

>Thanks.
>
>--
>tejun
>_______________________________________________
>Uclinux-dist-devel mailing list
>Uclinux-dist-devel@...ckfin.uclinux.org
>https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives