Re: [Kern Meetup Blr] Digest for kernel-meetup-bangalore@googlegroups.com - 9 updates in 7 topics

30 views
Skip to first unread message

Pintu Agarwal

unread,
May 31, 2024, 6:26:16 AMMay 31
to kernel-meet...@googlegroups.com
Hi All,
 
I would like to present the following topic for the June, 29th 2024 event.
 
Title: Enhancing the PSI framework in Linux Kernel
Abstract:
In any system the overall system congestion behavior mainly revolves around
CPU work-load, memory-pressure and IO-wait. From the 4.20 kernel onwards, a
new interface called Pressure Stall Information (PSI) is added in Linux
Kernel to track these work loads. But the problem is, it just gives the
overall average load value in the system in the last 10 seconds, 1 min and
5 min duration.
In this paper we are proposing to enhance the PSI module in Kernel to show
each task level break-up of resource usage under debug level. We have also
developed a new system resource monitoring daemon (SRMD) to monitor these
usage and take appropriate action. It can help to detect and predict system
congestion at an early stage and provide accurate information for
debugging. We will also present some interesting experimentation results
based on real scenarios.
 
Outline:
Introduction to PSI
Problem Statement
PSI Load Calculation Internals
Proposed Solution and changes
Details about SRMD
Experimentation Results
Conclusion

Talk preference: Regular talk

Note: This talk is also proposed for Linux Plumber Conference
Earlier I have presented 5 talks in Embedded Linux Conference, worldwide.
 
Thanks,
Pintu

On Fri, 31 May 2024 at 05:19, <kernel-meet...@googlegroups.com> wrote:
Pintu Agarwal <pintu...@gmail.com>: May 30 11:00PM +0530

Hi All,
 
If the slot is still available, I would like to present the following topic
for the June, 29th 2024 event.
 
Title: Enhancing the PSI framework in Linux Kernel
Abstract:
In any system the overall system congestion behavior mainly revolves around
CPU work-load, memory-pressure and IO-wait. From the 4.20 kernel onwards, a
new interface called Pressure Stall Information (PSI) is added in Linux
Kernel to track these work loads. But the problem is, it just gives the
overall average load value in the system in the last 10 seconds, 1 min and
5 min duration.
In this paper we are proposing to enhance the PSI module in Kernel to show
each task level break-up of resource usage under debug level. We have also
developed a new system resource monitoring daemon (SRMD) to monitor these
usage and take appropriate action. It can help to detect and predict system
congestion at an early stage and provide accurate information for
debugging. We will also present some interesting experimentation results
based on real scenarios.
 
Outline:
Introduction to PSI
Problem Statement
PSI Load Calculation Internals
Proposed Solution and changes
Details about SRMD
Experimentation Results
Conclusion
 
 
Thanks,
Pintu
 
On Tue, 28 May 2024 at 05:17, <kernel-meet...@googlegroups.com>
wrote:
 
Nilay Shroff <shroff...@gmail.com>: May 30 07:20PM +0530

Hi All.
 
Here's my talk proposal for June 29th,2024 meetup.
 
Thanks,
--Nilay
 
Title: Improve NVMe multipath IO performance on numa aware system
 
Abstract:
NVMe (nonvolatile memory express) is a storage access and transport
protocol for flash and next-generation solid-state drives (SSDs) that
delivers the highest throughput and fastest response times yet for all
types of enterprise workloads. Today, in both consumer apps and business,
users expect ever-faster response times. To help deliver a high-bandwidth,
low-latency user experience, the NVMe protocol accesses flash storage via a
PCI Express (PCIe) bus, which supports tens of thousands of parallel command
queues and thus is much faster than hard disks and traditional all-flash
architectures, which are limited to a single command queue.
 
The NVMe spec 1.1 added support for multipath I/O (with namespace sharing
capability) for further improving performance. The NVMe native multipath
implementation in the kernel supports different IO policies for different
workloads.
One of those IO policies is NUMA. Typically, on a numa aware system, the
user
would choose NUMA as the default IO policy.
 
In this talk I would cover, the performance issue we faced on numa-aware
system with NVMe multipath. I would then cover how we approached fixing the
performance issue which helped us improve the NVMe multipath performance
(upto ~12%) on a three numa-node system. The performance gain would be even
higher as the numa-node count increases.
 
Agenda: This talk will cover the following points:
1. Brief history/background about NVMe
2. The NVMe native multipath design in kernel
3. Discuss different IO policies supported by NVMe native multipath driver
code
4. Show the performance impact of the NUMA IO policy on PPC and how it was
addressed to
improve NVMe multi-controller disk performance.
5. Describe the other open issues in this space and get feedback from the
forum
 
Talk Preference: Regular Talk
 
Reference:
https://lore.kernel.org/all/20240416082102...@linux.ibm.com/
https://lore.kernel.org/all/20240516121358....@linux.ibm.com/
https://lore.kernel.org/all/20240517142531....@linux.ibm.com/
Shrikanth Hegde <sshe...@gmail.com>: May 30 02:07PM +0530

Hi Raghavendra.
 
Maybe we can combine into one talk?
 
On Thu, May 30, 2024 at 12:38 AM Raghavendra KT <raghave...@gmail.com>
wrote:
 
Santosh Shukla <santosh.s...@gmail.com>: May 30 02:55PM +0530


> Hi Raghavendra.
 
> Maybe we can combine into one talk?
 
Indeed - Similar topic with slight difference in scoping. Please do!
 
Regards,
Santosh
Santosh Shukla <santosh.s...@gmail.com>: May 30 02:31AM -0700

CFP on behalf of Donet - His email bounced and also I am not able to post
as separate thread - Somehow google grps ML sends and then deletes later so
using thread to record Donet CFP.
 
------------
Hi all,
 
Here is my talk proposal for the June 29th meetup.
 
Thanks
Donet Tom
 
Topic: Improve memory tiering and mempolicy interface for heterogeneous
memory systems
 
With advancement in new technology, memory devices like CXL, HBM,
heterogeneous memory systems are going to be more and more common in
future. Even today systems can have different banks of memory attached to
different numa nodes which can have different bandwidth / latency
characteristics. Hence a lot of research has been going on to improve
memory tiering and memory allocation policies for such heterogeneous
systems.
 
In this talk I would like to discuss the work that we have been doing to
improve this area. More specifically about the challenges we faced with
current promotion/demotion in memory tiering and the broken mempolicy
interface. I would like to then talk about how we improved memory tiering
and mempolicy interface for such systems. With this work we were able to
see good performance improvement with memcached workload on our test setup
(upto ~70%). This work of ours is now upstreamed in v6.10-rc1 [1][2].
 
Agenda -
1. Background/Motivation
2. Brief intro on memory tiers, promotion/demotion of hot/cold pages into
different tiers.
3. Briefly cover Mempolicy - which is about controlling allocation policies
to a given set of numa nodes.
4. Problems/experiments/benchmarking and discussing our implementation.
5. Discuss other open problems in this space and collect ideas from this
forum.
 
[1]:
https://lore.kernel.org/linux-mm/20240517192239.9285...@linux-foundation.org/
[2]:
https://lore.kernel.org/all/cover.17113736...@linux.ibm.com/
 
Talk preference: Regular talk
 
On Thursday, May 30, 2024 at 2:55:54 PM UTC+5:30 Santosh Shukla wrote:
 
 
> Hi Raghavendra.
 
> Maybe we can combine into one talk?
 
Indeed - Similar topic with slight difference in scoping. Please do!
 
Regards,
Santosh
> On Thu, May 30, 2024 at 12:38 AM Raghavendra KT <raghave...@gmail.com>
wrote:
 
>>> Call for Proposals (CFP):
 
>>> The Call for Proposals (CFP) for this meetup will officially open soon.
>>> We invite you to share your insights, experiences, and knowledge with
the community.
>>> Bangalore Kernel Meetup Core Grp
 
>> --
>> You received this message because you are subscribed to the Google
Groups "Kernel Meetup Bangalore" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an email to kernel-meetup-ban...@googlegroups.com.
>> To view this discussion on the web, visit
https://groups.google.com/d/msgid/kernel-meetup-bangalore/c9e53827-9e6e-4332-9630-b8546abaad15n%40googlegroups.com.
 
 
> --
> You received this message because you are subscribed to the Google Groups
"Kernel Meetup Bangalore" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to kernel-meetup-ban...@googlegroups.com.
> To view this discussion on the web, visit
https://groups.google.com/d/msgid/kernel-meetup-bangalore/CAG9Yh81NVWL_%2BK-G77jkJOnj2ZebvdAhyLmFoLqf5W7PqRHvpw%40mail.gmail.com.
Hari Bathini <harikri...@gmail.com>: May 29 11:26PM -0700

Hi All,
 
Here is my talk proposal for Meetup scheduled on 29th June, 2024.
 
Thanks
Hari
 
Title: Firmware-Assisted Dump, an alternative kernel dump capturing
mechanism
 
Abstract:
On almost all architectures, kdump has been the default or the only
mechanism,
to capture kernel dump, for close to two decades. FADump (Firmware-Assisted
Dump)
is being used as the alternative dump capturing mechanism for over a
decade, on
ppc64. This presentation talks about why FADump was introduced, it's
shortcomings
and how those shortcomings were addressed over the course of time and why
FADump
was persisted with despite it's shortcomings.
 
Outline:
This presentation gives a brief introduction of kdump and FADump, the two
kernel
dump capturing mechanisms on ppc64. Then dwelves into the shortcomings of
each
approach. How these shortcomings were addressed. Where things stand today
and
what the future could hold for kernel crash dump capturing.
 
Talk Preference: Regular
Prateek Nayak <kprate...@gmail.com>: May 30 09:12AM +0530

Hello everyone,
 
Here is my talk proposal for the June 29th meetup. Please forgive the
formatting (or lack thereof) since I'm sending this from my phone.
 
Regards,
Prateek
--
 
Title: sched-scoreboard or: How I learned to stop worrying and debug
scheduling issues.
 
Presenters: K. Prateek Nayak
 
 
 
Abstract: In this live demo, we will take a look at how to debug a real
world scheduler problem with sched-scoreboard [1]. The demo will cover
the usage of the tool to monitor a workload, interpreting the reports
generated from the run, and neat little data processing tricks to make
it easier to narrow down the search space. We will breakdown reports
from a real world EEVDF regression [2], link the observation to the
implementation details, and ways of reporting the details back to the
scheduler community.
 
Outline:
- A demo of sched-scoreboard while running a workload and a look at the
reports generated.
- Data processing tricks adopted along the way to make the analysis
easier.
- Comparing reports for a workload that showed regression with the
Introduction of EEVDF scheduling strategy.
- A carefree stroll through the task wakeup path to correlate the
observation for above.
- Steps to use the data to help guide the patch authors or propose
solutions upstream yourself.
 
References:
[1] https://github.com/AMDESE/sched-scoreboard
[2]
https://lore.kernel.org/lkml/18199afa-16e2-8e76...@amd.com/
 
Talk preference: Regular talk
Himanshu Chauhan <hima...@thechauhan.dev>: May 30 09:04AM +0530

*Title:* ACPI and RAS support for RISC-V Architecture
 
*Abstract:* We will cover the ACPI specification changes and a brief
overview
of power and performance management on RISC-V architecture.
Subsequently, we will
go over the design and implementation of RAS on ACPI based RISC-V
platforms.
 
*Outline: *
1) ACPI for RISC-V high level overview
   1.1) RISC-V Hart capabilities information
   1.2) Interrupt controllers
   1.3 IOMMU
   1.4 NUMA
2) Power/Performance management
   2.1) LPI
   2.2) CPPC
3) Design of RAS for RISC-V
   3.1) RAS: What and Why?
   3.2) Quick RERI walkthrough
   3.3) APEI specification walkthrough
   3.4) Overview of error propagation and logging
   3.5) Quick demo (Optional)
 
Regards
 
Himanshu and Sunil
Santosh Shukla <santosh.s...@gmail.com>: May 29 08:27PM -0700

Hello Everyone,
 
We are extending CFP closing date from 31st May to 2nd June so to allow
more proposal inflows - We appreciate so far received proposal and
encouraging more proposal.
 
We will announce the shortlisted Proposals and meetup schedule by 10th June.
Registration opening date is 17th June.
 
Thank You!
 
Best Regards,
Bangalore Kernel Meetup Core Grp.
You have received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to kernel-meetup-ban...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages