On Mon, Apr 11, 2016 at 04:51:47PM +0200, Alexander Potapenko wrote:
> On Mon, Apr 11, 2016 at 4:39 PM, Alexander Potapenko <glider@xxxxxxxxxx> wrote:
> > On Mon, Apr 11, 2016 at 9:44 AM, Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> wrote:
> >> On Mon, Mar 14, 2016 at 11:43:43AM +0100, Alexander Potapenko wrote:
> >>> +depot_stack_handle_t depot_save_stack(struct stack_trace *trace,
> >>> + gfp_t alloc_flags)
> >>> +{
> >>> + u32 hash;
> >>> + depot_stack_handle_t retval = 0;
> >>> + struct stack_record *found = NULL, **bucket;
> >>> + unsigned long flags;
> >>> + struct page *page = NULL;
> >>> + void *prealloc = NULL;
> >>> + bool *rec;
> >>> +
> >>> + if (unlikely(trace->nr_entries == 0))
> >>> + goto fast_exit;
> >>> +
> >>> + rec = this_cpu_ptr(&depot_recursion);
> >>> + /* Don't store the stack if we've been called recursively. */
> >>> + if (unlikely(*rec))
> >>> + goto fast_exit;
> >>> + *rec = true;
> >>> +
> >>> + hash = hash_stack(trace->entries, trace->nr_entries);
> >>> + /* Bad luck, we won't store this stack. */
> >>> + if (hash == 0)
> >>> + goto exit;
> >>
> >> Hello,
> >>
> >> why is hash == 0 skipped?
> >>
> >> Thanks.
> > We have to keep a special value to distinguish allocations for which
> > we don't have the stack trace for some reason.
> > Making 0 such a value seems natural.
> Well, the above statement is false.
> Because we only compare the hash to the records that are already in
> the depot, there's no point in reserving this value.
So, could you make a patch for it?
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>