All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Alexander Potapenko <glider@google.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <pcc@google.com>,
	<andreyknvl@gmail.com>, <andriy.shevchenko@linux.intel.com>,
	<linux@rasmusvillemoes.dk>, <yury.norov@gmail.com>,
	<alexandru.elisei@arm.com>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <eugenis@google.com>,
	<syednwaris@gmail.com>, <william.gray@linaro.org>
Subject: Re: [PATCH v11 2/2] lib/test_bitmap: add tests for bitmap_{read,write}()
Date: Thu, 9 Nov 2023 15:32:46 +0100	[thread overview]
Message-ID: <27f5d15b-28da-469b-9625-1c840f33b60d@intel.com> (raw)
In-Reply-To: <CAG_fn=W3LqtdDoUDDVGn_=2+gvKNeCusH6yUzWmVmMmOLZp9jA@mail.gmail.com>

From: Alexander Potapenko <glider@google.com>
Date: Thu, 9 Nov 2023 15:28:56 +0100

>>
>> Could we maybe rather extend __check_eq_uint to take ulongs? Doesn't
>> seem like they differ a lot.
> 
> We could redefine expect_eq_uint as:
> 
> #define expect_eq_uint(x, y)           expect_eq_ulong((unsigned
> int)(x), (unsigned int)(y))

Do we need explicit casts here tho?

> 
> and throw __expect_eq_uint away.
> 
> 
>>> +     }
>>> +     time = ktime_get() - time;
>>> +     pr_err("Time spent in %s:\t%llu\n", __func__, time);
>>
>> pr_err() is for printing errors and is shown in red by some log readers.
>> Maybe use pr_info() or pr_notice()? Definitely not an error or even warning.
> 
> Note that test_bitmap.c has 17 calls of pr_err() and 7 calls of
> pr_warn(), which aren't really consistent (e.g. they are used in
> certain __check helpers instead of pr_err()), and the existing
> performance tests are calling pr_err().

Correct, and that's what caught my attention: visual grepping for bitmap
messages makes no sense because some of them are red even thought all
tests pass correctly.

> I can change that in a separate patch, if you think it's worth the
> effort: the error messages should probably remain pr_err(), but the
> informational ones could be made pr_info().

Sounds good to be, would be nice to see!

[...]

>>> @@ -1237,6 +1411,9 @@ static void __init selftest(void)
>>>       test_bitmap_cut();
>>>       test_bitmap_print_buf();
>>>       test_bitmap_const_eval();
>>> +     test_bitmap_read_write();
>>> +     test_bitmap_read_perf();
>>> +     test_bitmap_write_perf();
>>>
>>>       test_find_nth_bit();
>>>       test_for_each_set_bit();
>>
>> Thanks,
>> Olek
> 
> 
> 
> --
> Alexander Potapenko
> Software Engineer
> 
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
> 
> Geschäftsführer: Paul Manicle, Liana Sebastian
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg

Thanks,
Olek

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Alexander Potapenko <glider@google.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <pcc@google.com>,
	<andreyknvl@gmail.com>, <andriy.shevchenko@linux.intel.com>,
	<linux@rasmusvillemoes.dk>, <yury.norov@gmail.com>,
	<alexandru.elisei@arm.com>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <eugenis@google.com>,
	<syednwaris@gmail.com>, <william.gray@linaro.org>
Subject: Re: [PATCH v11 2/2] lib/test_bitmap: add tests for bitmap_{read,write}()
Date: Thu, 9 Nov 2023 15:32:46 +0100	[thread overview]
Message-ID: <27f5d15b-28da-469b-9625-1c840f33b60d@intel.com> (raw)
In-Reply-To: <CAG_fn=W3LqtdDoUDDVGn_=2+gvKNeCusH6yUzWmVmMmOLZp9jA@mail.gmail.com>

From: Alexander Potapenko <glider@google.com>
Date: Thu, 9 Nov 2023 15:28:56 +0100

>>
>> Could we maybe rather extend __check_eq_uint to take ulongs? Doesn't
>> seem like they differ a lot.
> 
> We could redefine expect_eq_uint as:
> 
> #define expect_eq_uint(x, y)           expect_eq_ulong((unsigned
> int)(x), (unsigned int)(y))

Do we need explicit casts here tho?

> 
> and throw __expect_eq_uint away.
> 
> 
>>> +     }
>>> +     time = ktime_get() - time;
>>> +     pr_err("Time spent in %s:\t%llu\n", __func__, time);
>>
>> pr_err() is for printing errors and is shown in red by some log readers.
>> Maybe use pr_info() or pr_notice()? Definitely not an error or even warning.
> 
> Note that test_bitmap.c has 17 calls of pr_err() and 7 calls of
> pr_warn(), which aren't really consistent (e.g. they are used in
> certain __check helpers instead of pr_err()), and the existing
> performance tests are calling pr_err().

Correct, and that's what caught my attention: visual grepping for bitmap
messages makes no sense because some of them are red even thought all
tests pass correctly.

> I can change that in a separate patch, if you think it's worth the
> effort: the error messages should probably remain pr_err(), but the
> informational ones could be made pr_info().

Sounds good to be, would be nice to see!

[...]

>>> @@ -1237,6 +1411,9 @@ static void __init selftest(void)
>>>       test_bitmap_cut();
>>>       test_bitmap_print_buf();
>>>       test_bitmap_const_eval();
>>> +     test_bitmap_read_write();
>>> +     test_bitmap_read_perf();
>>> +     test_bitmap_write_perf();
>>>
>>>       test_find_nth_bit();
>>>       test_for_each_set_bit();
>>
>> Thanks,
>> Olek
> 
> 
> 
> --
> Alexander Potapenko
> Software Engineer
> 
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
> 
> Geschäftsführer: Paul Manicle, Liana Sebastian
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg

Thanks,
Olek

  reply	other threads:[~2023-11-09 14:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 15:32 [PATCH v11 1/2] lib/bitmap: add bitmap_{read,write}() Alexander Potapenko
2023-10-30 15:32 ` Alexander Potapenko
2023-10-30 15:32 ` [PATCH v11 2/2] lib/test_bitmap: add tests for bitmap_{read,write}() Alexander Potapenko
2023-10-30 15:32   ` Alexander Potapenko
2023-11-09 11:49   ` Alexander Lobakin
2023-11-09 11:49     ` Alexander Lobakin
2023-11-09 14:28     ` Alexander Potapenko
2023-11-09 14:28       ` Alexander Potapenko
2023-11-09 14:32       ` Alexander Lobakin [this message]
2023-11-09 14:32         ` Alexander Lobakin
2023-11-09 14:33         ` Alexander Potapenko
2023-11-09 14:33           ` Alexander Potapenko
2023-11-09 14:35         ` Alexander Potapenko
2023-11-09 14:35           ` Alexander Potapenko

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=27f5d15b-28da-469b-9625-1c840f33b60d@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=alexandru.elisei@arm.com \
    --cc=andreyknvl@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=eugenis@google.com \
    --cc=glider@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=pcc@google.com \
    --cc=syednwaris@gmail.com \
    --cc=will@kernel.org \
    --cc=william.gray@linaro.org \
    --cc=yury.norov@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.