I have a question to the alloc_bitmap. Currently it is allocated in init_page_allocator() and is continous physical memory mapped in direct map (1:1 map) range. Would it be possible to support un-continous like what''s done for frame table? Several reason I can think out that can be improved is: a) if memory sparsed arranged, like large hole in the memory, it may cost some memory b) if we want to support memory hot add, we can''t increase this bitmap. c) this map is not NUMA aware, I''m not sure if it has any performance impact, although it is not accessed frequently. Any idea on it? Thanks Yunhong Jiang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/9/08 16:16, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:> I have a question to the alloc_bitmap. Currently it is allocated in > init_page_allocator() and is continous physical memory mapped in direct map > (1:1 map) range. Would it be possible to support un-continous like what''s done > for frame table? > Several reason I can think out that can be improved is: a) if memory sparsed > arranged, like large hole in the memory, it may cost some memory b) if we want > to support memory hot add, we can''t increase this bitmap. c) this map is not > NUMA aware, I''m not sure if it has any performance impact, although it is not > accessed frequently. > > Any idea on it?Yes, it could be sparsely allocated in future. No reason why not. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <mailto:keir.fraser@eu.citrix.com> wrote:> On 18/9/08 16:16, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > >> I have a question to the alloc_bitmap. Currently it is allocated in >> init_page_allocator() and is continous physical memory mapped in direct map >> (1:1 map) range. Would it be possible to support un-continous like what''s >> done for frame table? Several reason I can think out that can be improved >> is: a) if memory sparsed arranged, like large hole in the memory, it may >> cost some memory b) if we want to support memory hot add, we can''t >> increase this bitmap. c) this map is not NUMA aware, I''m not sure if it >> has any performance impact, although it is not accessed frequently. >> >> Any idea on it? > > Yes, it could be sparsely allocated in future. No reason why not.Thanks for your clarification. We ask this because we are considering memory online. Yunhong Jiang> > -- Keir_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/9/08 10:17, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:>>> Any idea on it? >> >> Yes, it could be sparsely allocated in future. No reason why not. > > Thanks for your clarification. We ask this because we are considering memory > online.I would suggest we allocate a virtual address range for the bitmap and then demand-populate mappings in that area. Just as we do for the frame_table. The alternative is an explicit radix tree data structure, but we may as well make use of the page-table structures to do the lookup work for us. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
FYI, I''m working on a patch that requires radix trees and have borrowed a bunch of code from Linux for it. I had to make a few changes to generalize the code (e.g. callouts for node alloc/free); if it would be useful, please let me know and I will post it.> -----Original Message----- > From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > Sent: Friday, September 19, 2008 3:32 AM > To: Jiang, Yunhong; xen-devel@lists.xensource.com; Wang, Shane > Subject: Re: [Xen-devel] One question on alloc_bitmap > > > On 19/9/08 10:17, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > > >>> Any idea on it? > >> > >> Yes, it could be sparsely allocated in future. No reason why not. > > > > Thanks for your clarification. We ask this because we are > considering memory > > online. > > I would suggest we allocate a virtual address range for the > bitmap and then > demand-populate mappings in that area. Just as we do for the > frame_table. > > The alternative is an explicit radix tree data structure, but > we may as well > make use of the page-table structures to do the lookup work for us. > > -- Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sure, can you please share the patch to avoid duplicate patch? Thanks Yunhong Jiang Daniel Magenheimer <mailto:dan.magenheimer@oracle.com> wrote:> FYI, I''m working on a patch that requires radix trees and > have borrowed a bunch of code from Linux for it. I had > to make a few changes to generalize the code (e.g. > callouts for node alloc/free); if it would be useful, > please let me know and I will post it. > >> -----Original Message----- >> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >> Sent: Friday, September 19, 2008 3:32 AM >> To: Jiang, Yunhong; xen-devel@lists.xensource.com; Wang, Shane >> Subject: Re: [Xen-devel] One question on alloc_bitmap >> >> >> On 19/9/08 10:17, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >> >>>>> Any idea on it? >>>> >>>> Yes, it could be sparsely allocated in future. No reason why not. >>> >>> Thanks for your clarification. We ask this because we are considering >>> memory online. >> >> I would suggest we allocate a virtual address range for the >> bitmap and then >> demand-populate mappings in that area. Just as we do for the frame_table. >> >> The alternative is an explicit radix tree data structure, but >> we may as well >> make use of the page-table structures to do the lookup work for us. >> >> -- Keir >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Um, I was suggesting we *don''t* use an explicit radix tree in this case (I assume Dan has a diffeent scenario where he actually requires an explicit radix tree structure). For alloc_bitmap[] we can stitch together a linear virtual address space using page tables, just as we do for frame_table[]. -- Keir On 22/9/08 06:35, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote:> Sure, can you please share the patch to avoid duplicate patch? > > Thanks > Yunhong Jiang > > Daniel Magenheimer <mailto:dan.magenheimer@oracle.com> wrote: >> FYI, I''m working on a patch that requires radix trees and >> have borrowed a bunch of code from Linux for it. I had >> to make a few changes to generalize the code (e.g. >> callouts for node alloc/free); if it would be useful, >> please let me know and I will post it. >> >>> -----Original Message----- >>> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >>> Sent: Friday, September 19, 2008 3:32 AM >>> To: Jiang, Yunhong; xen-devel@lists.xensource.com; Wang, Shane >>> Subject: Re: [Xen-devel] One question on alloc_bitmap >>> >>> >>> On 19/9/08 10:17, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >>> >>>>>> Any idea on it? >>>>> >>>>> Yes, it could be sparsely allocated in future. No reason why not. >>>> >>>> Thanks for your clarification. We ask this because we are considering >>>> memory online. >>> >>> I would suggest we allocate a virtual address range for the >>> bitmap and then >>> demand-populate mappings in that area. Just as we do for the frame_table. >>> >>> The alternative is an explicit radix tree data structure, but >>> we may as well >>> make use of the page-table structures to do the lookup work for us. >>> >>> -- Keir >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com >>> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser <mailto:keir.fraser@eu.citrix.com> wrote:> Um, I was suggesting we *don''t* use an explicit radix tree in > this case (I > assume Dan has a diffeent scenario where he actually requires > an explicit > radix tree structure). For alloc_bitmap[] we can stitch > together a linear > virtual address space using page tables, just as we do for frame_table[].We were working on using the virtual address method like frame_table. I asked patch from Dan just because I thought he already implemented patch for this and want to avoid conflct. If he is using radix tree for other purpose, that''s ok. Yunhong Jiang> > -- Keir > > On 22/9/08 06:35, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: > >> Sure, can you please share the patch to avoid duplicate patch? >> >> Thanks >> Yunhong Jiang >> >> Daniel Magenheimer <mailto:dan.magenheimer@oracle.com> wrote: >>> FYI, I''m working on a patch that requires radix trees and >>> have borrowed a bunch of code from Linux for it. I had >>> to make a few changes to generalize the code (e.g. >>> callouts for node alloc/free); if it would be useful, >>> please let me know and I will post it. >>> >>>> -----Original Message----- >>>> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >>>> Sent: Friday, September 19, 2008 3:32 AM >>>> To: Jiang, Yunhong; xen-devel@lists.xensource.com; Wang, Shane >>>> Subject: Re: [Xen-devel] One question on alloc_bitmap >>>> >>>> >>>> On 19/9/08 10:17, "Jiang, Yunhong" <yunhong.jiang@intel.com> wrote: >>>> >>>>>>> Any idea on it? >>>>>> >>>>>> Yes, it could be sparsely allocated in future. No reason why not. >>>>> >>>>> Thanks for your clarification. We ask this because we are considering >>>>> memory online. >>>> >>>> I would suggest we allocate a virtual address range for the >>>> bitmap and then >>>> demand-populate mappings in that area. Just as we do for the frame_table. >>>> >>>> The alternative is an explicit radix tree data structure, but >>>> we may as well >>>> make use of the page-table structures to do the lookup work for us. >>>> >>>> -- Keir >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com >>>> http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel