On Wed, May 30, 2012 at 4:46 AM, Mark Dixon <[email protected]> wrote: > Whoops, just re-read that and realised it could be misconstrued.
Hi Mark, Don't worry - as we don't have face-to-face communication, I think it is generally accepted that we all should have a higher level of tolerance for everything by default. > Just to make clear: this isn't about me wanting to get others to write code, > this is about trying to get agreement about how a gridengine feature should > look and behave to the user. Don't be afraid of sending us criticisms or suggestions - esp. if there is a strong technical case to back them. And we did more or less similar things when Grid Engine was under Sun's control, for example - the dynamic spooling framework that we asked Sun to support (instead of only supporting BerkeleyDB spooling - which means non-NFSv4 servers would lack the shadow master functionality): http://markmail.org/message/35mxwlh7efjooihw http://markmail.org/message/tcdwt2zt62wtlx7z And BTW, this was Andy's response: http://markmail.org/message/lfodw6hrekxsxsvv In the past, we provided suggestions with some real use cases (or technical reasons), and we gave Sun time to design & change the code. Even when Oracle was deciding whether to continue the Grid Engine open source project in 2010, we did not fork the project right away - we always respect the original project maintainers and let them do things that are good for everyone. We care about Grid Engine now as much as (or even more than) before, but like Sun, we also need time to change the design and also develop the code. As long as people don't repeatedly send us the same criticism every month, then we wouldn't mind getting them - even if we were to not do anything with it, at least this shows that you do care about this mission-critical software! > I'm still continuing with my patchset, and will post it publicly, because > the cluster I'm putting in now needs cgroup memory control and an > independently set h_vmem. I hope to ditch the patchset once the > ScalableLogic code becomes the norm, as it sounds like a cleaner > implementation. I was working on William's suggestion of supporting additional GIDs for cgroups - I think it fits the "Everything is a file in Unix" philosophy nicely. > I'm provisionally using the name h_mem / s_mem to control cgroup memory > enforcement, but am willing to be argued into changing this. Can you define a name for the "memsw.limit_in_bytes" cgroup memory controller limit?? Last week, I asked Ron Chen to work with the kernel mailing list guys to see if we can get the behavior that you & others are requesting... but I guess even if the Linux kernel were to add this functionality, it would still take ages for distributions to switch to a new kernel. Rayson > > > Best wishes, > > Mark > -- > ----------------------------------------------------------------- > Mark Dixon Email : [email protected] > HPC/Grid Systems Support Tel (int): 35429 > Information Systems Services Tel (ext): +44(0)113 343 5429 > University of Leeds, LS2 9JT, UK > ----------------------------------------------------------------- _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
