Re: [RFC 9/9] prd: Add support for page struct mapping

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

 



On 08/13/2014 05:26 AM, Boaz Harrosh wrote:
> +#ifdef CONFIG_BLK_DEV_PMEM_USE_PAGES
> +static int prd_add_page_mapping(phys_addr_t phys_addr, size_t total_size,
> +				void **o_virt_addr)
> +{
> +	int nid = memory_add_physaddr_to_nid(phys_addr);
> +	unsigned long start_pfn = phys_addr >> PAGE_SHIFT;
> +	unsigned long nr_pages = total_size >> PAGE_SHIFT;
> +	unsigned int start_sec = pfn_to_section_nr(start_pfn);
> +	unsigned int end_sec = pfn_to_section_nr(start_pfn + nr_pages - 1);

Nit: any chance you'd change this to be an exclusive end?  In the mm
code, we usually do:

	unsigned int end_sec = pfn_to_section_nr(start_pfn + nr_pages);

so the for loops end up <end_sec instead of <=end_sec.

> +	unsigned long phys_start_pfn;
> +	struct page **page_array, **mapped_page_array;
> +	unsigned long i;
> +	struct vm_struct *vm_area;
> +	void *virt_addr;
> +	int ret = 0;

This is a philosophical thing, but I don't see *ANY* block-specific code
in here.  Seems like this belongs in mm/ to me.

Is there a reason you don't just do this at boot and have to use hotplug
at runtime for it?  What are the ratio of pmem to RAM?  Is it possible
to exhaust all of RAM with 'struct page's for pmem?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux