Messages in this thread | | | Date | Fri, 27 Feb 2009 15:56:40 +0100 | Subject | Re: [PATCH] mm: get_nid_for_pfn() returns int | From | roel kluin <> |
| |
>> > > get_nid_for_pfn() returns int
>> > My mistake. Good catch.
>> Presumably the (nid < 0) case has never happened. > > We do know that it is happening on one system while creating > a symlink for a memory section so it should also happen on > the same system if unregister_mem_sect_under_nodes() were > called to remove the same symlink. > > The test was actually added in response to a problem with an > earlier version reported by Yasunori Goto where one or more > of the leading pages of a memory section on the 2nd node of > one of his systems was uninitialized because I believe they > coincided with a memory hole. The earlier version did not > ignore uninitialized pages and determined the nid by considering > only the 1st page of each memory section. This caused the > symlink to the 1st memory section on the 2nd node to be > incorrectly created in /sys/devices/system/node/node0 instead > of /sys/devices/system/node/node1. The problem was fixed by > adding the test to skip over uninitialized pages. > > I suspect we have not seen any reports of the non-removal > of a symlink due to the incorrect declaration of the nid > variable in unregister_mem_sect_under_nodes() because > - systems where a memory section could have an uninitialized > range of leading pages are probably rare. > - memory remove is probably not done very frequently on the > systems that are capable of demonstrating the problem. > - lingering symlink(s) that should have been removed may > have simply gone unnoticed. >> >> Should we retain the test? > > Yes. > >> >> Is silently skipping the node in that case desirable behaviour? > > It actually silently skips pages (not nodes) in it's quest > for valid nids for all the nodes that the memory section scans. > This is definitely desirable. > > I hope this answers your questions.
This still isn't applied, was it lost?
Roel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |