Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/20/2011 3:59 PM, Arnd Bergmann wrote: Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 Another problem with the existing interface is that it doesn't currently support PID name spaces. That could of course be retrofitted, but having the data split by pid directory would make it work implicitly. Another approach would be to have a /proc/hardwall/ directory with one entry per hardwall instance, and symlinks from /proc/pid/hardwall to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the hardwall entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. 2x2 1,1). Individual tasks that are in the hardwall can be found by reading the hardwall files, and we can learn where they are bound in the hardwall by reading the stat file as is normal for learning process affinity. When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just tile is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
(Resending after marking LKML in my Thunderbird address book for no HTML.) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 Another problem with the existing interface is that it doesn't currently support PID name spaces. That could of course be retrofitted, but having the data split by pid directory would make it work implicitly. Another approach would be to have a /proc/hardwall/ directory with one entry per hardwall instance, and symlinks from /proc/pid/hardwall to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the hardwall entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. 2x2 1,1). Individual tasks that are in the hardwall can be found by reading the hardwall files, and we can learn where they are bound in the hardwall by reading the stat file as is normal for learning process affinity. When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just tile is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
(Resending with no HTML for LKML.) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 Another problem with the existing interface is that it doesn't currently support PID name spaces. That could of course be retrofitted, but having the data split by pid directory would make it work implicitly. Another approach would be to have a /proc/hardwall/ directory with one entry per hardwall instance, and symlinks from /proc/pid/hardwall to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the hardwall entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. 2x2 1,1). Individual tasks that are in the hardwall can be found by reading the hardwall files, and we can learn where they are bound in the hardwall by reading the stat file as is normal for learning process affinity. When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just tile is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: (Resending with no HTML for LKML.) On 5/20/2011 3:59 PM, Arnd Bergmann wrote: Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 Another problem with the existing interface is that it doesn't currently support PID name spaces. That could of course be retrofitted, but having the data split by pid directory would make it work implicitly. Another approach would be to have a /proc/hardwall/ directory with one entry per hardwall instance, and symlinks from /proc/pid/hardwall to the respective file. I went ahead and implemented this, and will send out a v2 patch shortly. I added the hardwall entry to both the tgid_base (since everything is reflected there) but also to the tid_base_stuff[], since it can be different (in principle) for different threads. Ok, sounds good. I played around with using a symlink, but the bottom line seems to be that if I make it a symlink (via a SYM() macro in the table) it always has to exist -- so what does it point to when there's no hardwall activated? I tried making it point to /dev/null, but that just seemed silly. In the end I made /proc/PID/hardwall a file, either empty, or else containing the hardwall id. ok. I suppose you could make a non-hardwall file that you can link to, but an empty file also sounds ok. The actual hardwalls are then in /proc/tile/hardwall/NN, where NN is the hardwall id. I wrote a very simple hardwall id allocate/free pair; the pid allocator seemed too tied to task_structs. We only need at most NR_CPUS hardwall ids, so it's pretty simple to just use a cpumask to hold the set of allocated hardwall IDs. ok. The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. 2x2 1,1). Individual tasks that are in the hardwall can be found by reading the hardwall files, and we can learn where they are bound in the hardwall by reading the stat file as is normal for learning process affinity. Be careful with listing PID values in the hardwall files, as the PIDs may not be unique or visible if you combine this with PID name spaces. I guess the right solution would be to only list the tasks that are present in the name space of the thread reading the file. When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial I don't see an easy way to put a directory in /sys/hypervisor. It seems complex to create a kobject and a suitable class, etc., just for a subdirectory. Or is there something simple I'm missing? I'll keep looking. I also suspect just tile is an adequate subdirectory name here in the context of /sys/hypervisor, e.g. /sys/hypervisor/tile/version. I just checked for other users. The only one I could find was drivers/xen/sys-hypervisor.c, and it also doesn't use a subdirectory to identify that hypervisor. It's probably more consistent if you also don't do it then. You can create a directory with multiple files using sysfs_create_group() as the xen code does, but not nested directories. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/25/2011 4:20 PM, Arnd Bergmann wrote: On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. 2x2 1,1). Individual tasks that are in the hardwall can be found by reading the hardwall files, and we can learn where they are bound in the hardwall by reading the stat file as is normal for learning process affinity. Be careful with listing PID values in the hardwall files, as the PIDs may not be unique or visible if you combine this with PID name spaces. I guess the right solution would be to only list the tasks that are present in the name space of the thread reading the file. Sorry not to be clearer -- I am no longer listing any PID values in the hardwall files, for that exact reason. You have to look at /proc/*/hardwall (or /proc/*/tasks/*/hardwall) to find the files that are in a particular hardwall. This pattern is not one that's normally directly useful, though, so I'm happy leaving it to userspace if it's desired. When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial I just checked for other users. The only one I could find was drivers/xen/sys-hypervisor.c, and it also doesn't use a subdirectory to identify that hypervisor. It's probably more consistent if you also don't do it then. You can create a directory with multiple files using sysfs_create_group() as the xen code does, but not nested directories. I'll look into sysfs_create_group(), and then send a revised patch with all the /proc and /sys changes. Thanks! -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Wednesday 25 May 2011 22:31:37 Chris Metcalf wrote: On 5/25/2011 4:20 PM, Arnd Bergmann wrote: On Wednesday 25 May 2011 21:18:05 Chris Metcalf wrote: The contents of the hardwall ID file are then just a cpulist of the cpus covered by the hardwall, rather than introducing a new convention (as quoted above, e.g. 2x2 1,1). Individual tasks that are in the hardwall can be found by reading the hardwall files, and we can learn where they are bound in the hardwall by reading the stat file as is normal for learning process affinity. Be careful with listing PID values in the hardwall files, as the PIDs may not be unique or visible if you combine this with PID name spaces. I guess the right solution would be to only list the tasks that are present in the name space of the thread reading the file. Sorry not to be clearer -- I am no longer listing any PID values in the hardwall files, for that exact reason. You have to look at /proc/*/hardwall (or /proc/*/tasks/*/hardwall) to find the files that are in a particular hardwall. This pattern is not one that's normally directly useful, though, so I'm happy leaving it to userspace if it's desired. Ok, thanks for the clarification. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Thursday 19 May 2011, Arnd Bergmann wrote: # cat /proc/tile/board board_part: 402-2-05 board_serial: NBS-5002-00012 chip_serial: P62338.01.110 chip_revision: A0 board_revision: 2.2 board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE # cat /proc/tile/switch control: mdio gbe/0 I think it's ok to have it below /sys/hypervisor, because the information is provided through a hypervisor ABI, even though it describes something else. This is more like /sys/firmware, but the boundaries between that and /sys/hypervisor are not clearly defined when running virtualized anyway. A minor point that I meant to bring up but had not gotten to: When you do a /sys/hypervisor/ interface, put everything into a subdirectory under /sys/hypervisor with the name of your hypervisor, to avoid naming conflicts, e.g. /sys/hypervisor/tilera-hv/board/board_serial Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/19/2011 11:22 AM, Arnd Bergmann wrote: On Thursday 19 May 2011, Chris Metcalf wrote: /proc/tile/board Information on part numbers, serial numbers, etc., of the hardware that the kernel is executing on /proc/tile/switch The type of control path for the onboard network switch, if any. These two report information about the hardware, not the hypervisor. For example: # cat /proc/tile/board board_part: 402-2-05 board_serial: NBS-5002-00012 chip_serial: P62338.01.110 chip_revision: A0 board_revision: 2.2 board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE # cat /proc/tile/switch control: mdio gbe/0 I think it's ok to have it below /sys/hypervisor, because the information is provided through a hypervisor ABI, even though it describes something else. This is more like /sys/firmware, but the boundaries between that and /sys/hypervisor are not clearly defined when running virtualized anyway. I'll create a /sys/hypervisor/board/ and report the attributes there. /proc/tile/hardwall Information on the set of currently active hardwalls (note that the implementation is already present in arch/tile/kernel/hardwall.c; this change just enables it) This one is not a hypervisor-related file. It just lists information about the set of Linux hardwalls currently active. Again, it's not primarily intended for programmatic use, but as a diagnostic tool. same here, I'd still put it into the hypervisor structure. Since /proc/tile/hardwall has no connection to the hypervisor whatsoever, I'm reluctant to put it under /sys/hypervisor. Perhaps in this case it would be reasonable to just have the hardwall subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? Or I could make the /dev/hardwall char device dump out the ASCII text that we currently get from /proc/hardwall if you read from it, which is a little weird but not inconceivable. For example it currently shows things like this: # cat /proc/tile/hardwall 2x2 1,1 pids: 484@2,1 479@1,1 2x2 0,3 pids: In this example 2x2 1,1 is a 2x2 grid of cpus starting at grid (x,y) position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Friday 20 May 2011 16:26:57 Chris Metcalf wrote: /proc/tile/hardwall Information on the set of currently active hardwalls (note that the implementation is already present in arch/tile/kernel/hardwall.c; this change just enables it) This one is not a hypervisor-related file. It just lists information about the set of Linux hardwalls currently active. Again, it's not primarily intended for programmatic use, but as a diagnostic tool. same here, I'd still put it into the hypervisor structure. Since /proc/tile/hardwall has no connection to the hypervisor whatsoever, I'm reluctant to put it under /sys/hypervisor. Ah, I see. I didn't notice that it was in the other file. You are absolutely right, this does not belong into /sys/hypervisor and fits well into procfs, we just need to find the right place. Perhaps in this case it would be reasonable to just have the hardwall subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? Or I could make the /dev/hardwall char device dump out the ASCII text that we currently get from /proc/hardwall if you read from it, which is a little weird but not inconceivable. For example it currently shows things like this: # cat /proc/tile/hardwall 2x2 1,1 pids: 484@2,1 479@1,1 2x2 0,3 pids: In this example 2x2 1,1 is a 2x2 grid of cpus starting at grid (x,y) position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On 5/20/2011 10:37 AM, Arnd Bergmann wrote: On Friday 20 May 2011 16:26:57 Chris Metcalf wrote: /proc/tile/hardwall Information on the set of currently active hardwalls (note that the implementation is already present in arch/tile/kernel/hardwall.c; this change just enables it) Ah, I see. I didn't notice that it was in the other file. You are absolutely right, this does not belong into /sys/hypervisor and fits well into procfs, we just need to find the right place. Perhaps in this case it would be reasonable to just have the hardwall subsystem put the file in /proc/driver/hardwall, or even /proc/hardwall? Or I could make the /dev/hardwall char device dump out the ASCII text that we currently get from /proc/hardwall if you read from it, which is a little weird but not inconceivable. For example it currently shows things like this: # cat /proc/tile/hardwall 2x2 1,1 pids: 484@2,1 479@1,1 2x2 0,3 pids: In this example 2x2 1,1 is a 2x2 grid of cpus starting at grid (x,y) position (1,1), with task 484 bound to the cpu at (x,y) position (2,1). Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 It's not unreasonable to do what you're suggesting, i.e. what's this task's hardwall?, but it's not something that we've come up with any kind of use case for in the past, so I'm not currently planning to implement this. If we did, I agree, your solution looks like the right one. The proposed /proc/tile/hardwall really is intended as system-wide information. Each hardwall (one line in the output file example above) corresponds to a struct file that may be shared by multiple processes (or threads). Processes may pass the struct file to other processes via fork (and maybe exec), or by passing it over Unix sockets. Then those processes can choose a cpu within a hardwall rectangle, affinitize to that cpu only, activate the hardwall fd with an ioctl(), and then get access from the OS so they can work together within a hardwall to exchange data across the Tilera user dynamic network (a wormhole routed grid network that moves data at 32 bits/cycle with almost no latency). Processes can create a new hardwall as long as it doesn't overlap geometrically with any other existing hardwall on the system. -- Chris Metcalf, Tilera Corp. http://www.tilera.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Friday 20 May 2011 17:00:47 Chris Metcalf wrote: Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 It's not unreasonable to do what you're suggesting, i.e. what's this task's hardwall?, but it's not something that we've come up with any kind of use case for in the past, so I'm not currently planning to implement this. If we did, I agree, your solution looks like the right one. It's fairly easy to aggregate in user space though, we do similar things for 'lsof' and 'top', which walk all of procfs in order to show the complete picture. This is obviously more overhead than walking the lists in the kernel, but still not an expensive operation, and it keeps the data format much simpler. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
On Friday 20 May 2011 17:13:25 Arnd Bergmann wrote: On Friday 20 May 2011 17:00:47 Chris Metcalf wrote: Any chance you can still restructure the information? I would recommend making it a first-class procfs member, since the data is really per-task. You can add a conditional entry to tgid_base_stuff[] in fs/proc/base.c to make it show up for each pid, and then just have the per-task information in there to do the lookup the other way round: # cat /proc/484/hardwall 2x2 1,1 @2,1 # cat /proc/479/hardwall 2x2 1,1 @1,1 It's not unreasonable to do what you're suggesting, i.e. what's this task's hardwall?, but it's not something that we've come up with any kind of use case for in the past, so I'm not currently planning to implement this. If we did, I agree, your solution looks like the right one. It's fairly easy to aggregate in user space though, we do similar things for 'lsof' and 'top', which walk all of procfs in order to show the complete picture. This is obviously more overhead than walking the lists in the kernel, but still not an expensive operation, and it keeps the data format much simpler. Another problem with the existing interface is that it doesn't currently support PID name spaces. That could of course be retrofitted, but having the data split by pid directory would make it work implicitly. Another approach would be to have a /proc/hardwall/ directory with one entry per hardwall instance, and symlinks from /proc/pid/hardwall to the respective file. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] arch/tile: add /proc/tile, /proc/sys/tile, and a sysfs cpu attribute
(adding virtualization mailing list) On Thursday 19 May 2011, Chris Metcalf wrote: On 5/19/2011 9:41 AM, Arnd Bergmann wrote: /proc/tile/hvconfig Detailed configuration description of the hypervisor config I'm concerned about moving this one out of /proc, since it's just (copious) free text. An hvconfig (hypervisor config) file describes hypervisor driver dedicated tiles that run things like network packet or PCIe ingress/egress processing, etc. In addition it lists hypervisor driver options, boot flags for the kernel, etc, all kinds of things -- and you can't really guarantee that it will fit on a 4KB page, though in practice it usually does. The hypervisor reads this file from the boot stream when it boots, and then makes it available to Linux not for Linux's use, or even for programmatic userspace use, but just for end users to be able to review and verify that the configuration they think they booted is really what they got, for customer remote debugging, etc. The remote debugging aspect makes truncation to page size a particularly worrisome idea. Since it's not the kernel that is imposing the format here, you could make it a binary sysfs attribute, which works in the same way as a proc file and does not have the size limitations. /proc/tile/board Information on part numbers, serial numbers, etc., of the hardware that the kernel is executing on /proc/tile/switch The type of control path for the onboard network switch, if any. These two report information about the hardware, not the hypervisor. For example: # cat /proc/tile/board board_part: 402-2-05 board_serial: NBS-5002-00012 chip_serial: P62338.01.110 chip_revision: A0 board_revision: 2.2 board_description: Tilera TILExpressPro-64, TILEPro64 processor (866 MHz-capable), 1 10GbE, 6 1GbE # cat /proc/tile/switch control: mdio gbe/0 I think it's ok to have it below /sys/hypervisor, because the information is provided through a hypervisor ABI, even though it describes something else. This is more like /sys/firmware, but the boundaries between that and /sys/hypervisor are not clearly defined when running virtualized anyway. The chip_serial and chip_revision can certainly hang off /sys/devices/system/cpu along with chip_height and chip_width (I've made this change now) but I don't know where the remaining board level description could go. Note that (as you can see in the source) certain boards will also include four lines of output with the mezzanine board part number, serial number, revision, and description; this particular example doesn't have a mezzanine board. The switch info is broken out into a separate file just to make it easier to script some /etc/rc code that launches a configurator for the Marvell switch on some of our boards, but is conceptually part of the board info. /proc/tile/hardwall Information on the set of currently active hardwalls (note that the implementation is already present in arch/tile/kernel/hardwall.c; this change just enables it) This one is not a hypervisor-related file. It just lists information about the set of Linux hardwalls currently active. Again, it's not primarily intended for programmatic use, but as a diagnostic tool. same here, I'd still put it into the hypervisor structure. Arnd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
