linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gioh Kim <gioh.kim@lge.com>
To: Laura Abbott <lauraa@codeaurora.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	John Stultz <john.stultz@linaro.org>,
	Rebecca Schultz Zavin <rebecca@android.com>
Cc: devel@driverdev.osuosl.org, gunho.lee@lge.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFCv2 2/3] staging: ion: debugfs to shrink pool
Date: Mon, 27 Oct 2014 09:24:45 +0900	[thread overview]
Message-ID: <544D90CD.3090107@lge.com> (raw)
In-Reply-To: <544AB8BD.70201@codeaurora.org>



2014-10-25 오전 5:38, Laura Abbott 쓴 글:
> Hi,
>
> On 10/23/2014 11:47 PM, Gioh Kim wrote:
>> This patch creates debugfs files, /sys/kernel/debug/ion/heaps/system_shrink,
>> to shrink pool or get pool size.
>> Reading the file returns pool size and writing occurs to shrink pool.
>>
>
> Can you clarify here that you are updating the existing debugfs
> infrastructure? Since the shrinker debugfs was commented out before
> it missed the API update so it would be good to note that as well.

OK, I will at the v2 patch.

>
>> Signed-off-by: Gioh Kim <gioh.kim@lge.com>
>> ---
>>   drivers/staging/android/ion/ion.c |   31 ++++++++-----------------------
>>   1 file changed, 8 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
>> index 290d4d2..ecc1121 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -1463,43 +1463,29 @@ static const struct file_operations debug_heap_fops = {
>>       .release = single_release,
>>   };
>>
>> -#ifdef DEBUG_HEAP_SHRINKER
>
> We're now unconditionally adding the shrinker debugfs. I'm not sure if
> this is something we want in production code. Could you turn this
> into a proper Kconfig?

The interface is via debugfs.
I think we don't turn on the debugfs in production code.

>
>>   static int debug_shrink_set(void *data, u64 val)
>>   {
>>       struct ion_heap *heap = data;
>> -    struct shrink_control sc;
>>       int objs;
>>
>> -    sc.gfp_mask = -1;
>> -    sc.nr_to_scan = 0;
>> -
>> -    if (!val)
>> -        return 0;
>> -
>> -    objs = heap->shrinker.shrink(&heap->shrinker, &sc);
>> -    sc.nr_to_scan = objs;
>> +    if (val)
>> +        objs = val;
>> +    else
>> +        objs = heap->ops->shrink(heap, __GFP_HIGHMEM, 0);
>>
>> -    heap->shrinker.shrink(&heap->shrinker, &sc);
>> +    (void)heap->ops->shrink(heap, __GFP_HIGHMEM, objs);
>
> The shrinker API now has separate functions for counting and scanning
> and ion wraps the calls to those as well to account for the deferred
> freelist. I realize the existing behavior may have been broken but the
> debugfs seems incomplete if it's not taking that into account as well.

ion_heap_shrink_count() and ion_heap_shrink_scan() are called by shrinker.
I think debug_shrink_set()/get() are for debugfs, so they can work without shrinker.

You can count deferred freelist via other debugfs file, for instance /sys/kernel/debug/ion/heaps/system.
I think debug_shrink_set()/get() should work by the number of pages in the pool.


>
>>       return 0;
>>   }
>>
>>   static int debug_shrink_get(void *data, u64 *val)
>>   {
>>       struct ion_heap *heap = data;
>> -    struct shrink_control sc;
>> -    int objs;
>> -
>> -    sc.gfp_mask = -1;
>> -    sc.nr_to_scan = 0;
>> -
>> -    objs = heap->shrinker.shrink(&heap->shrinker, &sc);
>> -    *val = objs;
>> +    *val = heap->ops->shrink(heap, __GFP_HIGHMEM, 0);
>>       return 0;
>>   }
>>
>>   DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
>>               debug_shrink_set, "%llu\n");
>> -#endif
>>
>>   void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
>>   {
>> @@ -1534,8 +1520,7 @@ void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
>>               path, heap->name);
>>       }
>>
>> -#ifdef DEBUG_HEAP_SHRINKER
>> -    if (heap->shrinker.shrink) {
>> +    if (heap->ops->shrink) {
>
> Technically a heap doesn't need to set ops->shrink to have a shrinker
> set up (not that it really matters for the current setup). Checking
> for scan_objects would be better.
>
>>           char debug_name[64];
>>
>>           snprintf(debug_name, 64, "%s_shrink", heap->name);
>> @@ -1550,7 +1535,7 @@ void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
>>                   path, debug_name);
>>           }
>>       }
>> -#endif
>> +
>>       up_write(&dev->lock);
>>   }
>>
>>
>
> Thanks,
> Laura
>

  reply	other threads:[~2014-10-27  0:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24  6:47 [RFCv2 0/3] enable pool shrinking in page unit Gioh Kim
2014-10-24  6:47 ` [RFCv2 1/3] staging: ion: shrink page-pool by " Gioh Kim
2014-10-24 20:09   ` Laura Abbott
2014-10-27  0:01     ` Gioh Kim
2014-10-24  6:47 ` [RFCv2 2/3] staging: ion: debugfs to shrink pool Gioh Kim
2014-10-24 20:38   ` Laura Abbott
2014-10-27  0:24     ` Gioh Kim [this message]
2014-10-24  6:47 ` [RFCv2 3/3] staging: ion: limit pool size Gioh Kim
2014-10-24 20:53   ` Laura Abbott
2014-10-27  0:48     ` Gioh Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=544D90CD.3090107@lge.com \
    --to=gioh.kim@lge.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gunho.lee@lge.com \
    --cc=john.stultz@linaro.org \
    --cc=lauraa@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rebecca@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).