Messages in this thread | | | Subject | Re: [RFC] Obtaining memory information for kexec/kdump | From | Dave Hansen <> | Date | Thu, 24 Mar 2005 07:32:51 -0800 |
| |
On Thu, 2005-03-24 at 15:49 +0530, Hariprasad Nellitheertha wrote: > Dave Hansen wrote: > > I think there's likely a lot of commonality with the needs of memory > > hotplug systems here. We effectively dump out the physical layout of > > the system, but in sysfs. We do this mostly because any memory hotplug > > changes generate hotplug events, just like all other hardware. If you > > do this in /proc, it's another thing that memory hotplug will have to > > update. > > We put it in /proc primarily because what we wanted was > similar in many ways to /proc/iomem and so we (re)use a bit > of the code.
The code reuse is nice, but the expanded use of /proc is not.
> Also, we were wondering if it is appropriate to > put in multiple values in a single file in sysfs.
Why would you need to do that? > I've attached a document I started writing a couple days ago > > about the sysfs layout and the call paths for hotplug. It's horribly > > incomplete, but not a bad start. > > > > If you want to see some more details of the layout, please check out > > this patch set: > > > > http://www.sr71.net/patches/2.6.12/2.6.12-rc1-mhp1/patch-2.6.12-rc1-mhp1.gz > > This does not have the sysfs related code. Is there a > separate patch for adding the sysfs entries?
Hmmm. I think my rollup script broke. Try this:
http://www.sr71.net/patches/2.6.12/2.6.12-rc1-mhp1/broken-out/L0-sysfs-memory-class.patch
> > block_size_bytes: The size of each memory section (in hex) > > This value is per memoryXXXX directory, right?
No, it's global. However, we have discussed doing it per-section in the future to collapse some of the contiguous areas into a single directory.
-- Dave
- 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/
| |