Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Atsushi. 2012/12/12 Atsushi Kumagai : > Hello, > > On Tue, 11 Dec 2012 17:17:05 -0500 (EST) > Dave Anderson wrote: > >> >> >> - Original Message - >> > On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: >> > >> > [..] >> > > > So without knowing details of both the data structures, I think if >> > > > vmlist >> > > > is going away, then user space tools should be able to traverse >> > > > vmap_area_root >> > > > rb tree. I am assuming it is sorted using ->addr field and we should be >> > > > able to get vmalloc area start from there. It will just be a matter of >> > > > exporting right fields to user space (instead of vmlist). >> > > >> > > There is address sorted list of vmap_area, vmap_area_list. >> > > So we can use it for traversing vmalloc areas if it is necessary. >> > > But, as I mentioned before, kexec write *just* address of vmlist and >> > > offset of vm_struct's address field. It imply that they don't traverse >> > > vmlist, >> > > because they didn't write vm_struct's next field which is needed for >> > > traversing. >> > > Without vm_struct's next field, they have no method for traversing. >> > > So, IMHO, assigning dummy vm_struct to vmlist which is implemented by >> > > [7/8] is >> > > a safe way to maintain a compatibility of userspace tool. :) >> > >> > Actually the design of "makedumpfile" and "crash" tool is that they know >> > about kernel data structures and they adopt to changes. So for major >> > changes they keep track of kernel version numbers and if access the >> > data structures accordingly. >> > >> > Currently we access first element of vmlist to determine start of vmalloc >> > address. True we don't have to traverse the list. >> > >> > But as you mentioned we should be able to get same information by >> > traversing to left most element of vmap_area_list rb tree. So I think >> > instead of trying to retain vmlist first element just for backward >> > compatibility, I will rather prefer get rid of that code completely >> > from kernel and let user space tool traverse rbtree. Just export >> > minimum needed info for traversal in user space. >> >> There's no need to traverse the rbtree. There is a vmap_area_list >> linked list of vmap_area structures that is also sorted by virtual >> address. >> >> All that makedumpfile would have to do is to access the first vmap_area >> in the vmap_area_list -- as opposed to the way that it does now, which is >> by accessing the first vm_struct in the to-be-obsoleted vmlist list. >> >> So it seems silly to keep the dummy "vmlist" around. > > I think so, I will modify makedumpfile to get the start address of vmalloc > with vmap_area_list if the related symbols are provided as VMCOREINFO like > vmlist. > BTW, have we to consider other tools ? > If it is clear, I think we can get rid of the dummy vmlist. Good! In next spin, I will remove dummy vmlist and export vmap_area_list symbol for makedumpfile. I don't know any other tools. If anyone knows it, please let me know. Thanks! Atsushi, Dave and Vivek. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Atsushi. 2012/12/12 Atsushi Kumagai kumagai-atsu...@mxc.nes.nec.co.jp: Hello, On Tue, 11 Dec 2012 17:17:05 -0500 (EST) Dave Anderson ander...@redhat.com wrote: - Original Message - On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: [..] So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Actually the design of makedumpfile and crash tool is that they know about kernel data structures and they adopt to changes. So for major changes they keep track of kernel version numbers and if access the data structures accordingly. Currently we access first element of vmlist to determine start of vmalloc address. True we don't have to traverse the list. But as you mentioned we should be able to get same information by traversing to left most element of vmap_area_list rb tree. So I think instead of trying to retain vmlist first element just for backward compatibility, I will rather prefer get rid of that code completely from kernel and let user space tool traverse rbtree. Just export minimum needed info for traversal in user space. There's no need to traverse the rbtree. There is a vmap_area_list linked list of vmap_area structures that is also sorted by virtual address. All that makedumpfile would have to do is to access the first vmap_area in the vmap_area_list -- as opposed to the way that it does now, which is by accessing the first vm_struct in the to-be-obsoleted vmlist list. So it seems silly to keep the dummy vmlist around. I think so, I will modify makedumpfile to get the start address of vmalloc with vmap_area_list if the related symbols are provided as VMCOREINFO like vmlist. BTW, have we to consider other tools ? If it is clear, I think we can get rid of the dummy vmlist. Good! In next spin, I will remove dummy vmlist and export vmap_area_list symbol for makedumpfile. I don't know any other tools. If anyone knows it, please let me know. Thanks! Atsushi, Dave and Vivek. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, On Tue, 11 Dec 2012 17:17:05 -0500 (EST) Dave Anderson wrote: > > > - Original Message - > > On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: > > > > [..] > > > > So without knowing details of both the data structures, I think if > > > > vmlist > > > > is going away, then user space tools should be able to traverse > > > > vmap_area_root > > > > rb tree. I am assuming it is sorted using ->addr field and we should be > > > > able to get vmalloc area start from there. It will just be a matter of > > > > exporting right fields to user space (instead of vmlist). > > > > > > There is address sorted list of vmap_area, vmap_area_list. > > > So we can use it for traversing vmalloc areas if it is necessary. > > > But, as I mentioned before, kexec write *just* address of vmlist and > > > offset of vm_struct's address field. It imply that they don't traverse > > > vmlist, > > > because they didn't write vm_struct's next field which is needed for > > > traversing. > > > Without vm_struct's next field, they have no method for traversing. > > > So, IMHO, assigning dummy vm_struct to vmlist which is implemented by > > > [7/8] is > > > a safe way to maintain a compatibility of userspace tool. :) > > > > Actually the design of "makedumpfile" and "crash" tool is that they know > > about kernel data structures and they adopt to changes. So for major > > changes they keep track of kernel version numbers and if access the > > data structures accordingly. > > > > Currently we access first element of vmlist to determine start of vmalloc > > address. True we don't have to traverse the list. > > > > But as you mentioned we should be able to get same information by > > traversing to left most element of vmap_area_list rb tree. So I think > > instead of trying to retain vmlist first element just for backward > > compatibility, I will rather prefer get rid of that code completely > > from kernel and let user space tool traverse rbtree. Just export > > minimum needed info for traversal in user space. > > There's no need to traverse the rbtree. There is a vmap_area_list > linked list of vmap_area structures that is also sorted by virtual > address. > > All that makedumpfile would have to do is to access the first vmap_area > in the vmap_area_list -- as opposed to the way that it does now, which is > by accessing the first vm_struct in the to-be-obsoleted vmlist list. > > So it seems silly to keep the dummy "vmlist" around. I think so, I will modify makedumpfile to get the start address of vmalloc with vmap_area_list if the related symbols are provided as VMCOREINFO like vmlist. BTW, have we to consider other tools ? If it is clear, I think we can get rid of the dummy vmlist. Thanks Atsushi Kumagai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
- Original Message - > On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: > > [..] > > > So without knowing details of both the data structures, I think if vmlist > > > is going away, then user space tools should be able to traverse > > > vmap_area_root > > > rb tree. I am assuming it is sorted using ->addr field and we should be > > > able to get vmalloc area start from there. It will just be a matter of > > > exporting right fields to user space (instead of vmlist). > > > > There is address sorted list of vmap_area, vmap_area_list. > > So we can use it for traversing vmalloc areas if it is necessary. > > But, as I mentioned before, kexec write *just* address of vmlist and > > offset of vm_struct's address field. It imply that they don't traverse > > vmlist, > > because they didn't write vm_struct's next field which is needed for > > traversing. > > Without vm_struct's next field, they have no method for traversing. > > So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] > > is > > a safe way to maintain a compatibility of userspace tool. :) > > Actually the design of "makedumpfile" and "crash" tool is that they know > about kernel data structures and they adopt to changes. So for major > changes they keep track of kernel version numbers and if access the > data structures accordingly. > > Currently we access first element of vmlist to determine start of vmalloc > address. True we don't have to traverse the list. > > But as you mentioned we should be able to get same information by > traversing to left most element of vmap_area_list rb tree. So I think > instead of trying to retain vmlist first element just for backward > compatibility, I will rather prefer get rid of that code completely > from kernel and let user space tool traverse rbtree. Just export > minimum needed info for traversal in user space. There's no need to traverse the rbtree. There is a vmap_area_list linked list of vmap_area structures that is also sorted by virtual address. All that makedumpfile would have to do is to access the first vmap_area in the vmap_area_list -- as opposed to the way that it does now, which is by accessing the first vm_struct in the to-be-obsoleted vmlist list. So it seems silly to keep the dummy "vmlist" around. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: [..] > > So without knowing details of both the data structures, I think if vmlist > > is going away, then user space tools should be able to traverse > > vmap_area_root > > rb tree. I am assuming it is sorted using ->addr field and we should be > > able to get vmalloc area start from there. It will just be a matter of > > exporting right fields to user space (instead of vmlist). > > There is address sorted list of vmap_area, vmap_area_list. > So we can use it for traversing vmalloc areas if it is necessary. > But, as I mentioned before, kexec write *just* address of vmlist and > offset of vm_struct's address field. > It imply that they don't traverse vmlist, > because they didn't write vm_struct's next field which is needed for > traversing. > Without vm_struct's next field, they have no method for traversing. > So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is > a safe way to maintain a compatibility of userspace tool. :) Actually the design of "makedumpfile" and "crash" tool is that they know about kernel data structures and they adopt to changes. So for major changes they keep track of kernel version numbers and if access the data structures accordingly. Currently we access first element of vmlist to determine start of vmalloc address. True we don't have to traverse the list. But as you mentioned we should be able to get same information by traversing to left most element of vmap_area_list rb tree. So I think instead of trying to retain vmlist first element just for backward compatibility, I will rather prefer get rid of that code completely from kernel and let user space tool traverse rbtree. Just export minimum needed info for traversal in user space. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
- Original Message - > > Can we get the same information from this rb-tree of vmap_area? Is > > ->va_start field communication same information as vmlist was > > communicating? What's the difference between vmap_area_root and vmlist. > > Thanks for comment. > > Yes. vmap_area's va_start field represent same information as vm_struct's > addr. > vmap_area_root is data structure for fast searching an area. > vmap_area_list is address sorted list, so we can use it like as vmlist. > > There is a little difference vmap_area_list and vmlist. > vmlist is lack of information about some areas in vmalloc address space. > For example, vm_map_ram() allocate area in vmalloc address space, > but it doesn't make a link with vmlist. To provide full information > about vmalloc address space, using vmap_area_list is more adequate. > > > So without knowing details of both the data structures, I think if vmlist > > is going away, then user space tools should be able to traverse > > vmap_area_root > > rb tree. I am assuming it is sorted using ->addr field and we should be > > able to get vmalloc area start from there. It will just be a matter of > > exporting right fields to user space (instead of vmlist). > > There is address sorted list of vmap_area, vmap_area_list. > So we can use it for traversing vmalloc areas if it is necessary. > But, as I mentioned before, kexec write *just* address of vmlist and > offset of vm_struct's address field. It imply that they don't traverse > vmlist, > because they didn't write vm_struct's next field which is needed for > traversing. > Without vm_struct's next field, they have no method for traversing. > So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is > a safe way to maintain a compatibility of userspace tool. :) Why bother keeping vmlist around? kdump's makedumpfile command would not even need to traverse the vmap_area rbtree, because it could simply look at the first vmap_area in the sorted vmap_area_list, correct? Dave Anderson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
- Original Message - Can we get the same information from this rb-tree of vmap_area? Is -va_start field communication same information as vmlist was communicating? What's the difference between vmap_area_root and vmlist. Thanks for comment. Yes. vmap_area's va_start field represent same information as vm_struct's addr. vmap_area_root is data structure for fast searching an area. vmap_area_list is address sorted list, so we can use it like as vmlist. There is a little difference vmap_area_list and vmlist. vmlist is lack of information about some areas in vmalloc address space. For example, vm_map_ram() allocate area in vmalloc address space, but it doesn't make a link with vmlist. To provide full information about vmalloc address space, using vmap_area_list is more adequate. So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Why bother keeping vmlist around? kdump's makedumpfile command would not even need to traverse the vmap_area rbtree, because it could simply look at the first vmap_area in the sorted vmap_area_list, correct? Dave Anderson -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: [..] So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Actually the design of makedumpfile and crash tool is that they know about kernel data structures and they adopt to changes. So for major changes they keep track of kernel version numbers and if access the data structures accordingly. Currently we access first element of vmlist to determine start of vmalloc address. True we don't have to traverse the list. But as you mentioned we should be able to get same information by traversing to left most element of vmap_area_list rb tree. So I think instead of trying to retain vmlist first element just for backward compatibility, I will rather prefer get rid of that code completely from kernel and let user space tool traverse rbtree. Just export minimum needed info for traversal in user space. Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
- Original Message - On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: [..] So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Actually the design of makedumpfile and crash tool is that they know about kernel data structures and they adopt to changes. So for major changes they keep track of kernel version numbers and if access the data structures accordingly. Currently we access first element of vmlist to determine start of vmalloc address. True we don't have to traverse the list. But as you mentioned we should be able to get same information by traversing to left most element of vmap_area_list rb tree. So I think instead of trying to retain vmlist first element just for backward compatibility, I will rather prefer get rid of that code completely from kernel and let user space tool traverse rbtree. Just export minimum needed info for traversal in user space. There's no need to traverse the rbtree. There is a vmap_area_list linked list of vmap_area structures that is also sorted by virtual address. All that makedumpfile would have to do is to access the first vmap_area in the vmap_area_list -- as opposed to the way that it does now, which is by accessing the first vm_struct in the to-be-obsoleted vmlist list. So it seems silly to keep the dummy vmlist around. Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, On Tue, 11 Dec 2012 17:17:05 -0500 (EST) Dave Anderson ander...@redhat.com wrote: - Original Message - On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote: [..] So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Actually the design of makedumpfile and crash tool is that they know about kernel data structures and they adopt to changes. So for major changes they keep track of kernel version numbers and if access the data structures accordingly. Currently we access first element of vmlist to determine start of vmalloc address. True we don't have to traverse the list. But as you mentioned we should be able to get same information by traversing to left most element of vmap_area_list rb tree. So I think instead of trying to retain vmlist first element just for backward compatibility, I will rather prefer get rid of that code completely from kernel and let user space tool traverse rbtree. Just export minimum needed info for traversal in user space. There's no need to traverse the rbtree. There is a vmap_area_list linked list of vmap_area structures that is also sorted by virtual address. All that makedumpfile would have to do is to access the first vmap_area in the vmap_area_list -- as opposed to the way that it does now, which is by accessing the first vm_struct in the to-be-obsoleted vmlist list. So it seems silly to keep the dummy vmlist around. I think so, I will modify makedumpfile to get the start address of vmalloc with vmap_area_list if the related symbols are provided as VMCOREINFO like vmlist. BTW, have we to consider other tools ? If it is clear, I think we can get rid of the dummy vmlist. Thanks Atsushi Kumagai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Vivek. 2012/12/7 Vivek Goyal : > On Fri, Dec 07, 2012 at 10:16:55PM +0900, JoonSoo Kim wrote: >> 2012/12/7 Andrew Morton : >> > On Fri, 7 Dec 2012 01:09:27 +0900 >> > Joonsoo Kim wrote: >> > >> >> I'm not sure that "7/8: makes vmlist only for kexec" is fine. >> >> Because it is related to userspace program. >> >> As far as I know, makedumpfile use kexec's output information and it only >> >> need first address of vmalloc layer. So my implementation reflect this >> >> fact, but I'm not sure. And now, I don't fully test this patchset. >> >> Basic operation work well, but I don't test kexec. So I send this >> >> patchset with 'RFC'. >> > >> > Yes, this is irritating. Perhaps Vivek or one of the other kexec >> > people could take a look at this please - if would obviously be much >> > better if we can avoid merging [patch 7/8] at all. >> >> I'm not sure, but I almost sure that [patch 7/8] have no problem. >> In kexec.c, they write an address of vmlist and offset of vm_struct's >> address field. >> It imply that user for this information doesn't have any other >> information about vm_struct, >> and they can't use other field of vm_struct. They can use *only* address >> field. >> So, remaining just one vm_struct for vmlist which represent first area >> of vmalloc layer >> may be safe. > > I browsed through makedumpfile source quickly. So yes it does look like > that we look at first vmlist element ->addr field to figure out where > vmalloc area is starting. > > Can we get the same information from this rb-tree of vmap_area? Is > ->va_start field communication same information as vmlist was > communicating? What's the difference between vmap_area_root and vmlist. Thanks for comment. Yes. vmap_area's va_start field represent same information as vm_struct's addr. vmap_area_root is data structure for fast searching an area. vmap_area_list is address sorted list, so we can use it like as vmlist. There is a little difference vmap_area_list and vmlist. vmlist is lack of information about some areas in vmalloc address space. For example, vm_map_ram() allocate area in vmalloc address space, but it doesn't make a link with vmlist. To provide full information about vmalloc address space, using vmap_area_list is more adequate. > So without knowing details of both the data structures, I think if vmlist > is going away, then user space tools should be able to traverse vmap_area_root > rb tree. I am assuming it is sorted using ->addr field and we should be > able to get vmalloc area start from there. It will just be a matter of > exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Vivek. 2012/12/7 Vivek Goyal vgo...@redhat.com: On Fri, Dec 07, 2012 at 10:16:55PM +0900, JoonSoo Kim wrote: 2012/12/7 Andrew Morton a...@linux-foundation.org: On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim js1...@gmail.com wrote: I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Yes, this is irritating. Perhaps Vivek or one of the other kexec people could take a look at this please - if would obviously be much better if we can avoid merging [patch 7/8] at all. I'm not sure, but I almost sure that [patch 7/8] have no problem. In kexec.c, they write an address of vmlist and offset of vm_struct's address field. It imply that user for this information doesn't have any other information about vm_struct, and they can't use other field of vm_struct. They can use *only* address field. So, remaining just one vm_struct for vmlist which represent first area of vmalloc layer may be safe. I browsed through makedumpfile source quickly. So yes it does look like that we look at first vmlist element -addr field to figure out where vmalloc area is starting. Can we get the same information from this rb-tree of vmap_area? Is -va_start field communication same information as vmlist was communicating? What's the difference between vmap_area_root and vmlist. Thanks for comment. Yes. vmap_area's va_start field represent same information as vm_struct's addr. vmap_area_root is data structure for fast searching an area. vmap_area_list is address sorted list, so we can use it like as vmlist. There is a little difference vmap_area_list and vmlist. vmlist is lack of information about some areas in vmalloc address space. For example, vm_map_ram() allocate area in vmalloc address space, but it doesn't make a link with vmlist. To provide full information about vmalloc address space, using vmap_area_list is more adequate. So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). There is address sorted list of vmap_area, vmap_area_list. So we can use it for traversing vmalloc areas if it is necessary. But, as I mentioned before, kexec write *just* address of vmlist and offset of vm_struct's address field. It imply that they don't traverse vmlist, because they didn't write vm_struct's next field which is needed for traversing. Without vm_struct's next field, they have no method for traversing. So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is a safe way to maintain a compatibility of userspace tool. :) Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Fri, Dec 07, 2012 at 10:16:55PM +0900, JoonSoo Kim wrote: > 2012/12/7 Andrew Morton : > > On Fri, 7 Dec 2012 01:09:27 +0900 > > Joonsoo Kim wrote: > > > >> I'm not sure that "7/8: makes vmlist only for kexec" is fine. > >> Because it is related to userspace program. > >> As far as I know, makedumpfile use kexec's output information and it only > >> need first address of vmalloc layer. So my implementation reflect this > >> fact, but I'm not sure. And now, I don't fully test this patchset. > >> Basic operation work well, but I don't test kexec. So I send this > >> patchset with 'RFC'. > > > > Yes, this is irritating. Perhaps Vivek or one of the other kexec > > people could take a look at this please - if would obviously be much > > better if we can avoid merging [patch 7/8] at all. > > I'm not sure, but I almost sure that [patch 7/8] have no problem. > In kexec.c, they write an address of vmlist and offset of vm_struct's > address field. > It imply that user for this information doesn't have any other > information about vm_struct, > and they can't use other field of vm_struct. They can use *only* address > field. > So, remaining just one vm_struct for vmlist which represent first area > of vmalloc layer > may be safe. I browsed through makedumpfile source quickly. So yes it does look like that we look at first vmlist element ->addr field to figure out where vmalloc area is starting. Can we get the same information from this rb-tree of vmap_area? Is ->va_start field communication same information as vmlist was communicating? What's the difference between vmap_area_root and vmlist. So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using ->addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). CCing Atsushi Kumagai and Dave Anderson. Atsushi-san is the one who maintains makedumpfile. Dave Anderson maintains "crash" and looks like it already has the capability to traverse through vmap_area_root rb-tree. So please let us know if left most element of vmap_area_root rb-tree will give us start of vmalloc area or not? Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Bob. 2012/12/7 Bob Liu : > Hi Joonsoo, > > On Fri, Dec 7, 2012 at 12:09 AM, Joonsoo Kim wrote: >> This patchset remove vm_struct list management after initializing vmalloc. >> Adding and removing an entry to vmlist is linear time complexity, so >> it is inefficient. If we maintain this list, overall time complexity of >> adding and removing area to vmalloc space is O(N), although we use >> rbtree for finding vacant place and it's time complexity is just O(logN). >> >> And vmlist and vmlist_lock is used many places of outside of vmalloc.c. >> It is preferable that we hide this raw data structure and provide >> well-defined function for supporting them, because it makes that they >> cannot mistake when manipulating theses structure and it makes us easily >> maintain vmalloc layer. >> >> I'm not sure that "7/8: makes vmlist only for kexec" is fine. >> Because it is related to userspace program. >> As far as I know, makedumpfile use kexec's output information and it only >> need first address of vmalloc layer. So my implementation reflect this >> fact, but I'm not sure. And now, I don't fully test this patchset. >> Basic operation work well, but I don't test kexec. So I send this >> patchset with 'RFC'. >> >> Please let me know what I am missing. >> > > Nice work! > I also thought about this several weeks ago but I think the efficiency > may be a problem. > > As you know two locks(vmap_area_lock and vmlist_lock) are used > currently so that some > work may be done in parallel(not proved). > If removed vmlist, i'm afraid vmap_area_lock will become a bottleneck > which will reduce the efficiency. Thanks for comment! Yes, there were some place that work may be done in parallel. For example, access to '/proc/meminfo', '/proc/vmallocinfo' and '/proc/kcore' may be done in parallel. But, access to these are not main functionality of vmalloc layer. Optimizing main function like vmalloc, vfree is more preferable than above. And this patchset optimize main function with removing vmlist iteration. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
2012/12/7 Andrew Morton : > On Fri, 7 Dec 2012 01:09:27 +0900 > Joonsoo Kim wrote: > >> I'm not sure that "7/8: makes vmlist only for kexec" is fine. >> Because it is related to userspace program. >> As far as I know, makedumpfile use kexec's output information and it only >> need first address of vmalloc layer. So my implementation reflect this >> fact, but I'm not sure. And now, I don't fully test this patchset. >> Basic operation work well, but I don't test kexec. So I send this >> patchset with 'RFC'. > > Yes, this is irritating. Perhaps Vivek or one of the other kexec > people could take a look at this please - if would obviously be much > better if we can avoid merging [patch 7/8] at all. I'm not sure, but I almost sure that [patch 7/8] have no problem. In kexec.c, they write an address of vmlist and offset of vm_struct's address field. It imply that user for this information doesn't have any other information about vm_struct, and they can't use other field of vm_struct. They can use *only* address field. So, remaining just one vm_struct for vmlist which represent first area of vmalloc layer may be safe. But, kexec people may be very helpful to validate this patch. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Andrew. 2012/12/7 Andrew Morton : > On Fri, 7 Dec 2012 01:09:27 +0900 > Joonsoo Kim wrote: > >> This patchset remove vm_struct list management after initializing vmalloc. >> Adding and removing an entry to vmlist is linear time complexity, so >> it is inefficient. If we maintain this list, overall time complexity of >> adding and removing area to vmalloc space is O(N), although we use >> rbtree for finding vacant place and it's time complexity is just O(logN). >> >> And vmlist and vmlist_lock is used many places of outside of vmalloc.c. >> It is preferable that we hide this raw data structure and provide >> well-defined function for supporting them, because it makes that they >> cannot mistake when manipulating theses structure and it makes us easily >> maintain vmalloc layer. >> >> I'm not sure that "7/8: makes vmlist only for kexec" is fine. >> Because it is related to userspace program. >> As far as I know, makedumpfile use kexec's output information and it only >> need first address of vmalloc layer. So my implementation reflect this >> fact, but I'm not sure. And now, I don't fully test this patchset. >> Basic operation work well, but I don't test kexec. So I send this >> patchset with 'RFC'. >> >> Please let me know what I am missing. >> >> This series based on v3.7-rc7 and on top of submitted patchset for ARM. >> 'introduce static_vm for ARM-specific static mapped area' >> https://lkml.org/lkml/2012/11/27/356 >> But, running properly on x86 without ARM patchset. > > This all looks rather nice, but not mergeable into anything at this > stage in the release cycle. > > What are the implications of "on top of submitted patchset for ARM"? > Does it depens on the ARM patches in any way, or it it independently > mergeable and testable? > Yes. It depends on ARM patches. There is a code to manipulate a vmlist in ARM. So without applying ARM patches, this patchset makes compile error for ARM. But, build for x86 works fine with this patchset :) In ARM patches, a method used for removing vmlist related code is same as 1/8 of this patchset. But, it includes some optimization for ARM, so I sent it separately. If it can't be accepted, I can rework ARM patches like as 1/8 of this patchset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Andrew. 2012/12/7 Andrew Morton a...@linux-foundation.org: On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim js1...@gmail.com wrote: This patchset remove vm_struct list management after initializing vmalloc. Adding and removing an entry to vmlist is linear time complexity, so it is inefficient. If we maintain this list, overall time complexity of adding and removing area to vmalloc space is O(N), although we use rbtree for finding vacant place and it's time complexity is just O(logN). And vmlist and vmlist_lock is used many places of outside of vmalloc.c. It is preferable that we hide this raw data structure and provide well-defined function for supporting them, because it makes that they cannot mistake when manipulating theses structure and it makes us easily maintain vmalloc layer. I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Please let me know what I am missing. This series based on v3.7-rc7 and on top of submitted patchset for ARM. 'introduce static_vm for ARM-specific static mapped area' https://lkml.org/lkml/2012/11/27/356 But, running properly on x86 without ARM patchset. This all looks rather nice, but not mergeable into anything at this stage in the release cycle. What are the implications of on top of submitted patchset for ARM? Does it depens on the ARM patches in any way, or it it independently mergeable and testable? Yes. It depends on ARM patches. There is a code to manipulate a vmlist in ARM. So without applying ARM patches, this patchset makes compile error for ARM. But, build for x86 works fine with this patchset :) In ARM patches, a method used for removing vmlist related code is same as 1/8 of this patchset. But, it includes some optimization for ARM, so I sent it separately. If it can't be accepted, I can rework ARM patches like as 1/8 of this patchset. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
2012/12/7 Andrew Morton a...@linux-foundation.org: On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim js1...@gmail.com wrote: I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Yes, this is irritating. Perhaps Vivek or one of the other kexec people could take a look at this please - if would obviously be much better if we can avoid merging [patch 7/8] at all. I'm not sure, but I almost sure that [patch 7/8] have no problem. In kexec.c, they write an address of vmlist and offset of vm_struct's address field. It imply that user for this information doesn't have any other information about vm_struct, and they can't use other field of vm_struct. They can use *only* address field. So, remaining just one vm_struct for vmlist which represent first area of vmalloc layer may be safe. But, kexec people may be very helpful to validate this patch. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hello, Bob. 2012/12/7 Bob Liu lliu...@gmail.com: Hi Joonsoo, On Fri, Dec 7, 2012 at 12:09 AM, Joonsoo Kim js1...@gmail.com wrote: This patchset remove vm_struct list management after initializing vmalloc. Adding and removing an entry to vmlist is linear time complexity, so it is inefficient. If we maintain this list, overall time complexity of adding and removing area to vmalloc space is O(N), although we use rbtree for finding vacant place and it's time complexity is just O(logN). And vmlist and vmlist_lock is used many places of outside of vmalloc.c. It is preferable that we hide this raw data structure and provide well-defined function for supporting them, because it makes that they cannot mistake when manipulating theses structure and it makes us easily maintain vmalloc layer. I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Please let me know what I am missing. Nice work! I also thought about this several weeks ago but I think the efficiency may be a problem. As you know two locks(vmap_area_lock and vmlist_lock) are used currently so that some work may be done in parallel(not proved). If removed vmlist, i'm afraid vmap_area_lock will become a bottleneck which will reduce the efficiency. Thanks for comment! Yes, there were some place that work may be done in parallel. For example, access to '/proc/meminfo', '/proc/vmallocinfo' and '/proc/kcore' may be done in parallel. But, access to these are not main functionality of vmalloc layer. Optimizing main function like vmalloc, vfree is more preferable than above. And this patchset optimize main function with removing vmlist iteration. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Fri, Dec 07, 2012 at 10:16:55PM +0900, JoonSoo Kim wrote: 2012/12/7 Andrew Morton a...@linux-foundation.org: On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim js1...@gmail.com wrote: I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Yes, this is irritating. Perhaps Vivek or one of the other kexec people could take a look at this please - if would obviously be much better if we can avoid merging [patch 7/8] at all. I'm not sure, but I almost sure that [patch 7/8] have no problem. In kexec.c, they write an address of vmlist and offset of vm_struct's address field. It imply that user for this information doesn't have any other information about vm_struct, and they can't use other field of vm_struct. They can use *only* address field. So, remaining just one vm_struct for vmlist which represent first area of vmalloc layer may be safe. I browsed through makedumpfile source quickly. So yes it does look like that we look at first vmlist element -addr field to figure out where vmalloc area is starting. Can we get the same information from this rb-tree of vmap_area? Is -va_start field communication same information as vmlist was communicating? What's the difference between vmap_area_root and vmlist. So without knowing details of both the data structures, I think if vmlist is going away, then user space tools should be able to traverse vmap_area_root rb tree. I am assuming it is sorted using -addr field and we should be able to get vmalloc area start from there. It will just be a matter of exporting right fields to user space (instead of vmlist). CCing Atsushi Kumagai and Dave Anderson. Atsushi-san is the one who maintains makedumpfile. Dave Anderson maintains crash and looks like it already has the capability to traverse through vmap_area_root rb-tree. So please let us know if left most element of vmap_area_root rb-tree will give us start of vmalloc area or not? Thanks Vivek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hi Joonsoo, On Fri, Dec 7, 2012 at 12:09 AM, Joonsoo Kim wrote: > This patchset remove vm_struct list management after initializing vmalloc. > Adding and removing an entry to vmlist is linear time complexity, so > it is inefficient. If we maintain this list, overall time complexity of > adding and removing area to vmalloc space is O(N), although we use > rbtree for finding vacant place and it's time complexity is just O(logN). > > And vmlist and vmlist_lock is used many places of outside of vmalloc.c. > It is preferable that we hide this raw data structure and provide > well-defined function for supporting them, because it makes that they > cannot mistake when manipulating theses structure and it makes us easily > maintain vmalloc layer. > > I'm not sure that "7/8: makes vmlist only for kexec" is fine. > Because it is related to userspace program. > As far as I know, makedumpfile use kexec's output information and it only > need first address of vmalloc layer. So my implementation reflect this > fact, but I'm not sure. And now, I don't fully test this patchset. > Basic operation work well, but I don't test kexec. So I send this > patchset with 'RFC'. > > Please let me know what I am missing. > Nice work! I also thought about this several weeks ago but I think the efficiency may be a problem. As you know two locks(vmap_area_lock and vmlist_lock) are used currently so that some work may be done in parallel(not proved). If removed vmlist, i'm afraid vmap_area_lock will become a bottleneck which will reduce the efficiency. > This series based on v3.7-rc7 and on top of submitted patchset for ARM. > 'introduce static_vm for ARM-specific static mapped area' > https://lkml.org/lkml/2012/11/27/356 > But, running properly on x86 without ARM patchset. > > Joonsoo Kim (8): > mm, vmalloc: change iterating a vmlist to find_vm_area() > mm, vmalloc: move get_vmalloc_info() to vmalloc.c > mm, vmalloc: protect va->vm by vmap_area_lock > mm, vmalloc: iterate vmap_area_list, instead of vmlist in > vread/vwrite() > mm, vmalloc: iterate vmap_area_list in get_vmalloc_info() > mm, vmalloc: iterate vmap_area_list, instead of vmlist, in > vmallocinfo() > mm, vmalloc: makes vmlist only for kexec > mm, vmalloc: remove list management operation after initializing > vmalloc > > arch/tile/mm/pgtable.c |7 +- > arch/unicore32/mm/ioremap.c | 17 +-- > arch/x86/mm/ioremap.c |7 +- > fs/proc/Makefile|2 +- > fs/proc/internal.h | 18 --- > fs/proc/meminfo.c |1 + > fs/proc/mmu.c | 60 -- > include/linux/vmalloc.h | 19 +++- > mm/vmalloc.c| 258 > +-- > 9 files changed, 204 insertions(+), 185 deletions(-) > delete mode 100644 fs/proc/mmu.c > > -- > 1.7.9.5 > -- Regards, --Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim wrote: > I'm not sure that "7/8: makes vmlist only for kexec" is fine. > Because it is related to userspace program. > As far as I know, makedumpfile use kexec's output information and it only > need first address of vmalloc layer. So my implementation reflect this > fact, but I'm not sure. And now, I don't fully test this patchset. > Basic operation work well, but I don't test kexec. So I send this > patchset with 'RFC'. Yes, this is irritating. Perhaps Vivek or one of the other kexec people could take a look at this please - if would obviously be much better if we can avoid merging [patch 7/8] at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim wrote: > This patchset remove vm_struct list management after initializing vmalloc. > Adding and removing an entry to vmlist is linear time complexity, so > it is inefficient. If we maintain this list, overall time complexity of > adding and removing area to vmalloc space is O(N), although we use > rbtree for finding vacant place and it's time complexity is just O(logN). > > And vmlist and vmlist_lock is used many places of outside of vmalloc.c. > It is preferable that we hide this raw data structure and provide > well-defined function for supporting them, because it makes that they > cannot mistake when manipulating theses structure and it makes us easily > maintain vmalloc layer. > > I'm not sure that "7/8: makes vmlist only for kexec" is fine. > Because it is related to userspace program. > As far as I know, makedumpfile use kexec's output information and it only > need first address of vmalloc layer. So my implementation reflect this > fact, but I'm not sure. And now, I don't fully test this patchset. > Basic operation work well, but I don't test kexec. So I send this > patchset with 'RFC'. > > Please let me know what I am missing. > > This series based on v3.7-rc7 and on top of submitted patchset for ARM. > 'introduce static_vm for ARM-specific static mapped area' > https://lkml.org/lkml/2012/11/27/356 > But, running properly on x86 without ARM patchset. This all looks rather nice, but not mergeable into anything at this stage in the release cycle. What are the implications of "on top of submitted patchset for ARM"? Does it depens on the ARM patches in any way, or it it independently mergeable and testable? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/8] remove vm_struct list management
This patchset remove vm_struct list management after initializing vmalloc. Adding and removing an entry to vmlist is linear time complexity, so it is inefficient. If we maintain this list, overall time complexity of adding and removing area to vmalloc space is O(N), although we use rbtree for finding vacant place and it's time complexity is just O(logN). And vmlist and vmlist_lock is used many places of outside of vmalloc.c. It is preferable that we hide this raw data structure and provide well-defined function for supporting them, because it makes that they cannot mistake when manipulating theses structure and it makes us easily maintain vmalloc layer. I'm not sure that "7/8: makes vmlist only for kexec" is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Please let me know what I am missing. This series based on v3.7-rc7 and on top of submitted patchset for ARM. 'introduce static_vm for ARM-specific static mapped area' https://lkml.org/lkml/2012/11/27/356 But, running properly on x86 without ARM patchset. Joonsoo Kim (8): mm, vmalloc: change iterating a vmlist to find_vm_area() mm, vmalloc: move get_vmalloc_info() to vmalloc.c mm, vmalloc: protect va->vm by vmap_area_lock mm, vmalloc: iterate vmap_area_list, instead of vmlist in vread/vwrite() mm, vmalloc: iterate vmap_area_list in get_vmalloc_info() mm, vmalloc: iterate vmap_area_list, instead of vmlist, in vmallocinfo() mm, vmalloc: makes vmlist only for kexec mm, vmalloc: remove list management operation after initializing vmalloc arch/tile/mm/pgtable.c |7 +- arch/unicore32/mm/ioremap.c | 17 +-- arch/x86/mm/ioremap.c |7 +- fs/proc/Makefile|2 +- fs/proc/internal.h | 18 --- fs/proc/meminfo.c |1 + fs/proc/mmu.c | 60 -- include/linux/vmalloc.h | 19 +++- mm/vmalloc.c| 258 +-- 9 files changed, 204 insertions(+), 185 deletions(-) delete mode 100644 fs/proc/mmu.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/8] remove vm_struct list management
This patchset remove vm_struct list management after initializing vmalloc. Adding and removing an entry to vmlist is linear time complexity, so it is inefficient. If we maintain this list, overall time complexity of adding and removing area to vmalloc space is O(N), although we use rbtree for finding vacant place and it's time complexity is just O(logN). And vmlist and vmlist_lock is used many places of outside of vmalloc.c. It is preferable that we hide this raw data structure and provide well-defined function for supporting them, because it makes that they cannot mistake when manipulating theses structure and it makes us easily maintain vmalloc layer. I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Please let me know what I am missing. This series based on v3.7-rc7 and on top of submitted patchset for ARM. 'introduce static_vm for ARM-specific static mapped area' https://lkml.org/lkml/2012/11/27/356 But, running properly on x86 without ARM patchset. Joonsoo Kim (8): mm, vmalloc: change iterating a vmlist to find_vm_area() mm, vmalloc: move get_vmalloc_info() to vmalloc.c mm, vmalloc: protect va-vm by vmap_area_lock mm, vmalloc: iterate vmap_area_list, instead of vmlist in vread/vwrite() mm, vmalloc: iterate vmap_area_list in get_vmalloc_info() mm, vmalloc: iterate vmap_area_list, instead of vmlist, in vmallocinfo() mm, vmalloc: makes vmlist only for kexec mm, vmalloc: remove list management operation after initializing vmalloc arch/tile/mm/pgtable.c |7 +- arch/unicore32/mm/ioremap.c | 17 +-- arch/x86/mm/ioremap.c |7 +- fs/proc/Makefile|2 +- fs/proc/internal.h | 18 --- fs/proc/meminfo.c |1 + fs/proc/mmu.c | 60 -- include/linux/vmalloc.h | 19 +++- mm/vmalloc.c| 258 +-- 9 files changed, 204 insertions(+), 185 deletions(-) delete mode 100644 fs/proc/mmu.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim js1...@gmail.com wrote: This patchset remove vm_struct list management after initializing vmalloc. Adding and removing an entry to vmlist is linear time complexity, so it is inefficient. If we maintain this list, overall time complexity of adding and removing area to vmalloc space is O(N), although we use rbtree for finding vacant place and it's time complexity is just O(logN). And vmlist and vmlist_lock is used many places of outside of vmalloc.c. It is preferable that we hide this raw data structure and provide well-defined function for supporting them, because it makes that they cannot mistake when manipulating theses structure and it makes us easily maintain vmalloc layer. I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Please let me know what I am missing. This series based on v3.7-rc7 and on top of submitted patchset for ARM. 'introduce static_vm for ARM-specific static mapped area' https://lkml.org/lkml/2012/11/27/356 But, running properly on x86 without ARM patchset. This all looks rather nice, but not mergeable into anything at this stage in the release cycle. What are the implications of on top of submitted patchset for ARM? Does it depens on the ARM patches in any way, or it it independently mergeable and testable? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
On Fri, 7 Dec 2012 01:09:27 +0900 Joonsoo Kim js1...@gmail.com wrote: I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Yes, this is irritating. Perhaps Vivek or one of the other kexec people could take a look at this please - if would obviously be much better if we can avoid merging [patch 7/8] at all. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/8] remove vm_struct list management
Hi Joonsoo, On Fri, Dec 7, 2012 at 12:09 AM, Joonsoo Kim js1...@gmail.com wrote: This patchset remove vm_struct list management after initializing vmalloc. Adding and removing an entry to vmlist is linear time complexity, so it is inefficient. If we maintain this list, overall time complexity of adding and removing area to vmalloc space is O(N), although we use rbtree for finding vacant place and it's time complexity is just O(logN). And vmlist and vmlist_lock is used many places of outside of vmalloc.c. It is preferable that we hide this raw data structure and provide well-defined function for supporting them, because it makes that they cannot mistake when manipulating theses structure and it makes us easily maintain vmalloc layer. I'm not sure that 7/8: makes vmlist only for kexec is fine. Because it is related to userspace program. As far as I know, makedumpfile use kexec's output information and it only need first address of vmalloc layer. So my implementation reflect this fact, but I'm not sure. And now, I don't fully test this patchset. Basic operation work well, but I don't test kexec. So I send this patchset with 'RFC'. Please let me know what I am missing. Nice work! I also thought about this several weeks ago but I think the efficiency may be a problem. As you know two locks(vmap_area_lock and vmlist_lock) are used currently so that some work may be done in parallel(not proved). If removed vmlist, i'm afraid vmap_area_lock will become a bottleneck which will reduce the efficiency. This series based on v3.7-rc7 and on top of submitted patchset for ARM. 'introduce static_vm for ARM-specific static mapped area' https://lkml.org/lkml/2012/11/27/356 But, running properly on x86 without ARM patchset. Joonsoo Kim (8): mm, vmalloc: change iterating a vmlist to find_vm_area() mm, vmalloc: move get_vmalloc_info() to vmalloc.c mm, vmalloc: protect va-vm by vmap_area_lock mm, vmalloc: iterate vmap_area_list, instead of vmlist in vread/vwrite() mm, vmalloc: iterate vmap_area_list in get_vmalloc_info() mm, vmalloc: iterate vmap_area_list, instead of vmlist, in vmallocinfo() mm, vmalloc: makes vmlist only for kexec mm, vmalloc: remove list management operation after initializing vmalloc arch/tile/mm/pgtable.c |7 +- arch/unicore32/mm/ioremap.c | 17 +-- arch/x86/mm/ioremap.c |7 +- fs/proc/Makefile|2 +- fs/proc/internal.h | 18 --- fs/proc/meminfo.c |1 + fs/proc/mmu.c | 60 -- include/linux/vmalloc.h | 19 +++- mm/vmalloc.c| 258 +-- 9 files changed, 204 insertions(+), 185 deletions(-) delete mode 100644 fs/proc/mmu.c -- 1.7.9.5 -- Regards, --Bob -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
