On 4/3/2021 8:21 AM, Ondrej Mosnacek wrote:
On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
wrote:
Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler (copied),
he said it might be
https://lore.kernel.org/selinux
On 9/30/2020 11:20 AM, Mike Kravetz wrote:
On 9/29/20 9:49 AM, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes should be
recalculated based on what is expected by khugepaged. Currently
after hotplug, min_free_kbytes will be set to a lower default
for THP consumers.
Fixes: f000565adb77 ("thp: set recommended min free kbytes")
Signed-off-by: Vijay Balakrishna
Cc: sta...@vger.kernel.org
Reviewed-by: Pavel Tatashin
Acked-by: Michal Hocko
---
v4 -> v5
- changelog: must -> should [Michal Hocko]
v3 -> v4
- m
for THP consumers.
Fixes: f000565adb77 ("thp: set recommended min free kbytes")
Signed-off-by: Vijay Balakrishna
Cc: sta...@vger.kernel.org
Reviewed-by: Pavel Tatashin
Acked-by: Michal Hocko
---
v3 -> v4
- made changes to move khugepaged_min_free_kbytes_update into
init_per_z
On 9/25/2020 12:42 AM, Michal Hocko wrote:
On Wed 16-09-20 18:21:48, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what is expected by khugepaged. Currently
after hotplug, min_free_kbytes will be set to a lower default
Can this patch be included? As Kirill is ok with patch now.
Thanks,
Vijay
On 9/16/2020 6:21 PM, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what is expected by khugepaged. Currently
after hotplug, min_free_kbytes
On 9/22/2020 3:07 AM, Michal Hocko wrote:
On Tue 22-09-20 10:07:26, Kirill A. Shutemov wrote:
On Mon, Sep 21, 2020 at 12:07:23PM -0700, Vijay Balakrishna wrote:
I would recommend reposting the patch which adds heuristic for THP (if
THP is enabled) into the hotplug path, arguing
On 9/17/2020 10:56 PM, Michal Hocko wrote:
On Thu 17-09-20 11:16:55, Vijay Balakrishna wrote:
On 9/17/2020 10:52 AM, Michal Hocko wrote:
On Thu 17-09-20 10:27:16, Vijay Balakrishna wrote:
On 9/17/2020 2:28 AM, Michal Hocko wrote:
On Wed 16-09-20 23:39:39, Vijay Balakrishna wrote
On 9/17/2020 10:45 PM, Michal Hocko wrote:
On Thu 17-09-20 11:03:56, Vijay Balakrishna wrote:
[...]
The auto tuned value is incorrect post hotplug memory operation, in our use
case memoy hot add occurs very early during boot.
Define incorrect. What are the actual values? Have you tried
On 9/17/2020 10:52 AM, Michal Hocko wrote:
On Thu 17-09-20 10:27:16, Vijay Balakrishna wrote:
On 9/17/2020 2:28 AM, Michal Hocko wrote:
On Wed 16-09-20 23:39:39, Vijay Balakrishna wrote:
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP
On 9/17/2020 5:12 AM, Michal Hocko wrote:
On Wed 16-09-20 11:28:40, Vijay Balakrishna wrote:
[...]
OOM splat below. I see we had kmem leak detection turned on here. We
haven't run stress with kmem leak detection since uncovereing low
min_free_kbytes. During investigation we wanted to make
On 9/17/2020 2:28 AM, Michal Hocko wrote:
On Wed 16-09-20 23:39:39, Vijay Balakrishna wrote:
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes, in particular when
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes, in particular when it is higher than
calculated recommended value.
Signed-off-by: Vijay Balakrishna
Cc: sta
lobals to 0
#43: FILE: mm/page_alloc.c:318:
+int user_min_free_kbytes = 0;
Sorry for trouble, I will send a new version.
Vijay
On 9/16/2020 6:21 PM, Vijay Balakrishna wrote:
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory h
for THP consumers.
Fixes: f000565adb77 ("thp: set recommended min free kbytes")
Signed-off-by: Vijay Balakrishna
Cc: sta...@vger.kernel.org
Reviewed-by: Pavel Tatashin
---
include/linux/khugepaged.h | 5 +
mm/khugepaged.c| 13 +++--
mm/memory_hotplug.c|
undesired result when comparing with "unsigned long" type.
Signed-off-by: Vijay Balakrishna
Cc: sta...@vger.kernel.org
Reviewed-by: Pavel Tatashin
---
mm/khugepaged.c | 3 ++-
mm/page_alloc.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/khugepaged.c b/mm/kh
Kirill A. Shutemov raised:
. changes would override min_free_kbytes set by user
Vijay Balakrishna (2):
mm: khugepaged: recalculate min_free_kbytes after memory hotplug as
expected by khugepaged
mm: khugepaged: avoid overriding min_free_kbytes set by user
include/linux/khugepaged.
On 9/16/2020 12:59 AM, Michal Hocko wrote:
On Tue 15-09-20 14:10:58, Vijay Balakrishna wrote:
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes, in particular when
On 9/15/2020 11:53 PM, Michal Hocko wrote:
On Tue 15-09-20 08:48:08, Vijay Balakrishna wrote:
On 9/15/2020 1:18 AM, Michal Hocko wrote:
On Mon 14-09-20 09:57:02, Vijay Balakrishna wrote:
On 9/14/2020 7:33 AM, Michal Hocko wrote:
On Thu 10-09-20 13:47:39, Vijay Balakrishna wrote:
When
On 9/15/2020 1:18 AM, Michal Hocko wrote:
On Mon 14-09-20 09:57:02, Vijay Balakrishna wrote:
On 9/14/2020 7:33 AM, Michal Hocko wrote:
On Thu 10-09-20 13:47:39, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what
iable
type to "int" from "unsigned long" to avoid undesired result noticed
during testing. It is due to comparing "unsigned long" with "int" type.
Signed-off-by: Vijay Balakrishna
Cc: sta...@vger.kernel.org
Reviewed-by: Pavel Tatashin
---
mm/khugepaged.
which isn't suitable for systems especially with network
intensive loads. Typical failure symptoms include HW WATCHDOG reset,
soft lockup hang notices, NETDEVICE WATCHDOG timeouts, and OOM process
kills.
Fixes: f000565adb77 ("thp: set recommended min free kbytes")
Signed-off-by: Vijay Balak
On 9/15/2020 11:27 AM, Pavel Tatashin wrote:
On Tue, Sep 15, 2020 at 12:55 AM Vijay Balakrishna
wrote:
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes
On 9/10/2020 3:01 PM, Kirill A. Shutemov wrote:
On Thu, Sep 10, 2020 at 01:47:39PM -0700, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what is expected by khugepaged. Currently
after hotplug, min_free_kbytes will be set
set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes, in particular when it is higher than
calculated recommended value.
Signed-off-by: Vijay Balakrishna
Cc: sta
On 9/14/2020 7:33 AM, Michal Hocko wrote:
On Thu 10-09-20 13:47:39, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what is expected by khugepaged. Currently
after hotplug, min_free_kbytes will be set to a lower default
On 9/10/2020 3:28 PM, Pavel Tatashin wrote:
Hi Kirill,
On Thu, Sep 10, 2020 at 6:01 PM Kirill A. Shutemov
wrote:
On Thu, Sep 10, 2020 at 01:47:39PM -0700, Vijay Balakrishna wrote:
When memory is hotplug added or removed the min_free_kbytes must be
recalculated based on what is expected
which isn't suitable for systems especially with network
intensive loads. Typical failure symptoms include HW WATCHDOG reset,
soft lockup hang notices, NETDEVICE WATCHDOG timeouts, and OOM process
kills.
Fixes: f000565adb77 ("thp: set recommended min free kbytes")
Signed-off-by: Vijay Balak
Thanks Andrew. See inline.
On 6/17/2020 12:45 PM, Andrew Morton wrote:
On Wed, 10 Jun 2020 21:27:52 -0700 Vijay Balakrishna
wrote:
Make kernel GNU build-id available in VMCOREINFO. Having
build-id in VMCOREINFO facilitates presenting appropriate kernel
namelist image with debug
methods for file types such as user mode crash
dumps, shared libraries, loadable kernel modules etc., This is an
exception for linux kernel dump. Having build-id in VMCOREINFO brings
some uniformity for automation tools.
Signed-off-by: Vijay Balakrishna
---
Changes since v2:
-
- v1
Thanks Baoquan. See inline.
On 6/9/2020 7:20 PM, Baoquan He wrote:
On 06/04/20 at 05:01pm, Vijay Balakrishna wrote:
Make kernel GNU build-id available in VMCOREINFO. Having
build-id in VMCOREINFO facilitates presenting appropriate kernel
namelist image with debug information file to kernel
-off-by: Vijay Balakrishna
---
Regarding if this patch is necessary or matching of linux_banner
and OSRELEASE in VMCOREINFO employed by crash(8) meets the
need -- IMO, build-id approach more foolproof, in most instances it
is a cryptographic hash generated using internal code/ELF bits unlike
kernel
32 matches
Mail list logo
