From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v4 03/15] xenctx: Add -m (--multiple_pages) option to output larger stack Date: Thu, 20 Mar 2014 10:52:44 +0000 Message-ID: <532AC87C.8090608@eu.citrix.com> References: <1395180940-23901-1-git-send-email-dslutz@verizon.com> <1395180940-23901-4-git-send-email-dslutz@verizon.com> <5329B8EF.2080000@eu.citrix.com> <532A4236.8060704@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <532A4236.8060704@terremark.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz Cc: Ian Campbell , Stefano Stabellini , Don Slutz , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 03/20/2014 01:19 AM, Don Slutz wrote: > On 03/19/14 11:34, George Dunlap wrote: >> On 03/18/2014 10:15 PM, Don Slutz wrote: >>> From: Don Slutz >>> >>> Important: This is the stack size to display not the configured >>> stack size. >>> >>> Using pictures (for a 3 page configured system): >>> >>> +------------------+ >>> | | >>> | | >>> | | >>> | | >>> | | >>> +------------------+ >>> | | >>> | | >>> | | >>> | | >>> | | >>> +------------------+ >>> | | >>> | | >>> | | >>> SP --> | | >>> | | >>> +------------------+ >> >> Sorry, what is this a picture of? I can't make any sense out of it. >> Shouldn't this have only one box, the next have two, and the bottom >> one have three? >> > > This is various pictures of a 3 page stack, and where the SP currently > is. Each box is a page. So here the "stack limit" is the end of 1 > page. In the sense of how much stack is used, you are right it is 1, > 2 and then 3. This tracks with the value passed for "-m" (see next > line). Oh, right: so you're saying that the developer running xenctx has to *guess* how many pages are currently in use? In other words, this really means, "Display N stack pages", and if you guessed too high, you'll get some pages worth of garbage. [snip] >>> int main(int argc, char **argv) >>> { >>> int ch; >>> int ret; >>> - static const char *sopts = "fs:hak:SC"; >>> + static const char *sopts = "fs:hak:SCm:"; >>> static const struct option lopts[] = { >>> {"stack-trace", 0, NULL, 'S'}, >>> {"symbol-table", 1, NULL, 's'}, >>> {"frame-pointers", 0, NULL, 'f'}, >>> {"kernel-start", 1, NULL, 'k'}, >>> + {"multiple-pages", 0, NULL, 'm'}, >> >> I think I would call the long option "kernel-stack-pages" or >> something like that. "Multiple pages" doesn't really convey much >> meaning. -m is probably a fine short option, but -n might be more >> memorable. >> > > The issue with "kernel-stack-pages" is that it leads to configured > kernel stack pages (which for the pictures above is 3). 3 is most > likely not the number to use here. > > A big part of this is that how a "kernel" knows where it is in the > stack can be simple like for a 2 page stack, 1 page is odd, 2nd page > is even. (3 pages is most likely more complex, but fence page(s) may > help here.) > > Maybe stack-limit-in-pages is better? Hmm -- "--display-stack-pages", and then say, "Display N pages from the stack pointer"? -George