[Announcement] Kernel Meetup Event June 29th - 2024

[Santosh Shukla]

Hello Bangalore Linux Kernel Developers,

I am excited to announce the Q2 Bangalore Kernel meetup event.

Event Details:
# Date: 29th June 2024
# Time: 9AM to 4:30PM
# Location: AMD India Pvt Ltd
Prestige Technostar
Doddanakundi Industrial Area 2,
Phase 1, Brookefield, Bengaluru,
Karnataka 560048
India

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.

CFP opens 20th May and closing 31st May.
Schedule and CFP announcement date 10th June.
Registration open date 17th June.

Theme for the meetup is
# Core Linux Kernel(Linux Scheduler, Locking and Sync, MM)
# Virtualization
# IO (IOMMU, NW, GPU, Storage, CXL)
# Multimedia (Audio, Video, Camera, Sensors)
# Power Management
# Secure Boot, Embedded, Security

See you all at Q2 Bangalore Linux Kernel Meetup on June 29th 2024.

Best Regards,
Bangalore Kernel Meetup Core Grp

[Vijay Kirpalani]

How do I register for the event ?

Thanks,

VIjay Kirpalani

[Santosh Shukla]

On Sat, 18 May, 2024, 10:27 Vijay Kirpalani, <vijayki...@gmail.com> wrote:

How do I register for the event ?

Registration opening date is 17th, watch out for registration opening announcement email from me and that email will have link to register.

Thx

--
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/5af84210-87b2-45e4-8e46-20c666e9e15en%40googlegroups.com.

[Sumadhura Kalyan]

Hi  All,

1. Title - RISC-V Architecture and Kernel Compilation Process for RISC-V.
2. Abstract - The RISC-V  architecture and its  TileLink protocol, this talk will explore more about the boot flow in the RISC-V architecture and instruction sets, Kernel compilation, and the Significance of architecture.
3. Outline - 

• A brief introduction to RISC-V.
• Instructions set.
• Comparison to other ISA.
• RISC-V pipeline architecture.
• Privilege modes(user modes, supervisor modes, machine modes..etc).
• TileLink Protocol over AXI.
• OpenSBI.
• Kernel compilation for RISC-V and QEMU.
• Impact of RISC-V.

Thanks,

Kalyan.S.

To view this discussion on the web, visit https://groups.google.com/d/msgid/kernel-meetup-bangalore/CACpj22x%3D0LZqYE9zCk7zYfqPfjB64x%3DoC5RH%3DbGp_kzsp1bZSg%40mail.gmail.com.

--

Regards,

s.kalyan,

[Kamlesh Gurudasani]

Hi all,

1. Title - Decrypting Linux kernel Crypto Subsystem
2. Abstract - Internals of crypto drivers, its uses and accessing the HW from userspace vs kernel space, performance and tests
3. Outline - 

• A brief introduction to Crypto APIs
• Adding driver of new hardware
• Adding new algorithm
• How it is different from other sub systems.
• Accessing it from userspace
• AF_ALG vs cryptodev
• zero copy interface
• Performance test 
• Integrity test
• IPSec vs Openssl

Regards, 

Kamlesh

To view this discussion on the web, visit https://groups.google.com/d/msgid/kernel-meetup-bangalore/CAHgV-fFXePC%3DfLSee%3DzYXrJ2WYGs-Fc3cLq5-TyybrE9%3DK_r0A%40mail.gmail.com.

[Smruti R. Sarangi]

Will this be streamed online?

S R Sarangi 

To view this discussion on the web, visit https://groups.google.com/d/msgid/kernel-meetup-bangalore/CANyTuOwu9cJ07QEVHtaJf7ugRB6%2BaCKK2rZkr0tD5jThstbOcw%40mail.gmail.com.

[Santosh Shukla]

On Monday, May 27, 2024 at 9:59:33 PM UTC+5:30 srsa...@gmail.com wrote:

Will this be streamed online?

In-person event.

Thanks 

[Santosh Shukla]

Somehow Anup's email bounced so fwding on his behalf to mail list.

Below is his proposal:

---------- Forwarded message ---------
From: Anup Patel <an...@brainfault.org>
Date: Tue, May 28, 2024 at 11:00 AM
Subject: Re: [Kern Meetup Blr] [Announcement] Kernel Meetup Event June
29th - 2024
To: Kernel Meetup Bangalore <kernel-meet...@googlegroups.com>
Cc: Santosh Shukla <santosh.s...@gmail.com>


Hi All,

I propose the following topic for the upcoming Linux Kernel Meetup on
June 29th 2024.

Title: RISC-V Landscape Overview
Abstract: An overview of the RISC-V landscape covering both
specifications and software ecosystem

Outline:
1) A short introduction of RISC-V
2) RISC-V International (RVI)
   2.1) What is RVI ?
   2.2) Navigating riscv.org ?
   2.3) Becoming a RVI member
   2.4) RVI organization structure
   2.5) RVI specification process
   2.6) Participating in a SIG/TG
3) RISC-V Software Ecosystem (RISE)
   3.1) Noteworthy RISC-V maintainers
   3.2) What is RISE ?
   3.3) RISE members
   3.4) RISE working groups
4) Ventana Contributions
   4.1) Ventana specification contributions
   4.2) Ventana software contributions
5) RISC-V Bleeding Edge

Regards,
Anup
---------

Thanks,

Santosh

[Raghavendra KT]

Hello Santhosh,

Title:  A Tale of clear page optimization proposal that led to Lazy
preemption.

Abstract:  One of the essential requirements of operating systems that
support paging mechanism is clearing the pages. Linux kernel
low level API currently supports clearing a single page. There are
proposals to optimize that to improve the performance of
clearing huge pages by combining multiple pages and exploiting
well known instructions supported by hardware.
However, slicing the big chunk of huge page into optimal blocks
is tricky for kernel.
If size of the blocks is too large it can potentially lead to stalls in
the kernel and reduce responsiveness.
Kernel Preemption models viz., none, voluntary and full also
decide how a stall condition is handled.
Lack of support for right preemption model has led to “lazy
preemption model (auto preemption)” proposal.

Agenda: This talk intends to cover,
1. Existing clear page support in Linux kernel.
2. How to potentially optimize for kernel for huge pages.
3. How preemption models affect the new clear huge page
proposal.
4. Introduction to new (pre-requisite) lazy preemption
model that helps in clear page optimization.

Thanks and Regards

- Raghu

PS: Just seeing a half overlap with proposal by Shrikant. 

[Shrikanth Hegde]

Hi Raghavendra. 

Maybe we can combine into one talk? 

--

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.

[Santosh Shukla]

On Thu, May 30, 2024 at 2:07 PM Shrikanth Hegde <sshe...@gmail.com> wrote:
>
> Hi Raghavendra.
>
> Maybe we can combine into one talk?
>

Indeed - Similar topic with slight difference in scoping. Please do!

Regards,
Santosh

> To view this discussion on the web, visit https://groups.google.com/d/msgid/kernel-meetup-bangalore/CAG9Yh81NVWL_%2BK-G77jkJOnj2ZebvdAhyLmFoLqf5W7PqRHvpw%40mail.gmail.com.

[Santosh Shukla]

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

[Meetakshi Setiya]

Hi all, here is my proposal

Title: Latency Tracing on Linux SMB Client using eBPF (Smbslower
and Smbvfsslower)

Abstract: Extended Berkeley Packet Filter (eBPF) support allows
custom analytic/diagnostic programs to be executed on Linux dynamic
tracing, static tracing, and profiling events. Libbpf provides a set
of APIs to the eBPF system and assist in loading and running eBPF
programs. For a network filesystem like SMB, eBPF scripts can come
handy to detect and diagnose client side delays in operations.
Smbslower and Smbvfsslower are tools we have developed at Azure Files
to trace all slow SMB operations in the cifs module and from the vfs
to the cifs module respectively. These low-overhead scripts trace all
possible respective operations, measure the time spent in these
operations, and print details for each that exceed a threshold. This
provides useful diagnostic information and helps pinpoint anomalies
on the client.

Outline:
    1) Intro to eBPF
    2) Intro to libbpf + CO-RE for writing eBPF scripts
    3) Intro to SMB and its operations
    4) Latency tracing for the Linux SMB Client
        a. Smbslower
            i. Intro
            ii. Demo
        b. Smbvfsslower
            i. Intro
            ii. Demo
   5) Benchmarks and overhead of the scripts

Thanks

Meetakshi

[Chinmay Rath]

Hey all,

Here is my talk proposal for Kernel meetup on 29th June:

Title: Moving Power ISA instructions to Decodetree spec in QEMU.

Abstract:

QEMU is a free and open-source emulator which provides both system and user-mode emulation. It supports a number of hypervisors, as well as a JIT known as the Tiny Code Generator (all known as accelerators in QEMU nomenclature), capable of emulating many CPUs. When used TCG as an accelerator, QEMU emulates the entire guest, including its CPU state and all its instructions in the software. Well, the first step, to emulate a guest instruction is to recognize the instruction correctly, in other words, decode it correctly, and efficiently, in way that is easy to maintain in the software.

QEMU supports more than a dozen different ISAs, this had resulted in a lot of idiosyncrasies within the decoding process of those ISAs, which caused a lot of trouble to maintain. That is when the good folks at QEMU came up with the Decodetree specification, which standardizes the manner in which the instructions are to be decoded.

In this talk, I intend to talk about my journey of moving > 300 Power ISA instructions to Decodetree specification, with the following agenda :

1. Brief introduction to QEMU and TCG.
2. Decodetree specification : Why was it needed in the first place ? What issue does it solve and how ? And why all ISAs are moving to it.
3. Decodetree specification in brief.
4. My experience of moving > 300 Power ISA instructions to the specification : process, challenges, testing and verification.
5. Room for improvements.

Talk Preference: Regular Talk

Reference (All patches merged/approved upstream):
https://lore.kernel.org/qemu-devel/20240214094027...@linux.ibm.com/
https://lore.kernel.org/qemu-devel/20240315064422...@linux.ibm.com/
https://lore.kernel.org/qemu-devel/20240416063927...@linux.ibm.com/
https://lore.kernel.org/qemu-devel/20240429051317...@linux.ibm.com/
https://lore.kernel.org/qemu-devel/20240523094454...@linux.ibm.com/
https://lore.kernel.org/qemu-devel/20240523094821...@linux.ibm.com/

Regards,

Chinmay Rath

[Souradeep Chakrabarti]

Hi All,

Title: TLB flushing in x86 architecture

Abstract: The x86 architecture's Translation Lookaside Buffer (TLB) plays a crucial role in memory management.

 It involves various TLB flushing mechanisms such as flush all, flush single page, and flush range. The CR3 and 

CR4 registers are integral to TLB flushing processes. Additionally, the significance of Process Context Identifiers (PCID),

 Invalidate Process-Context Identifier (INVPCID), and Page Table Isolation (PTI) in TLB flushing cannot be overstated. 

This discussion will also cover the operational differences between remote and local TLB flushing.

Outline:
1) A brief introduction on TLB
2)What triggers TLB flush
3)How TLB flushing happens
4)CR3, CR4 registers and MMU
5)How in x86 architecture uses IPI and invlpg, mov CR3 are used.
6)Criticality of INVPCID, PCID, and PTI in TLB flushing
7)Paravirt TLB flushing: (focus on Hyper-V)
8)Local and remote TLB flushing
9)Performance impact of TLB flushing, and also how Hypercall.
based TLB shootdown performance has got a boost from traditional
IPI based remote TLB flushing.

Thanks & Regards,

Souradeep Chakrabarti

On Friday, May 17, 2024 at 3:47:22 PM UTC+5:30 santosh.s...@gmail.com wrote:

[Santosh Shukla]

Vatsa is not able to post to google groups, mail bounced and its in my mbox so sending to mailing list.

Title: Introduction to Gunyah hypervisor

===

Gunyah is a high performance and scalable Type-1 hypervisor built for demanding
battery-powered, real-time, safety critical systems and currently supports
ARM64 architecture. A Linux driver for it is being developed taking active inputs
from kernel maintainers and community. It will allow applications such as Qemu
to interact with the hypervisor for VM management. The Linux driver is expected
to be merged upstream very soon this year. Support for gunyah hypervisor in Qemu
is also being developed concurrently with couple of versions already published.

In this session, we intend to briefly cover Gunyah hypervisor overview, proposed
features of its Linux driver and finally the proposed changes to Qemu for
supporting Gunyah. We discuss the proposed changes to manage both confidential
guests and non-confidential (aka unprotected) guests.

About the presenter:

Srivatsa Vaddagiri works as Principal Engineer at Qualcomm Innovation Center in Bangalore, India. He has over 20 years of experience working with various Unix kernels, including AIX and Linux. His Linux kernel contributions include cpu hotplug support and cgroup-aware extensions to CPU scheduler. At Qualcomm, Srivatsa's current focus is on enabling Linux support for Gunyah, a Type-1 hypervisor in Linux. Srivatsa holds a MS degree in Software systems from BITS, Pilani.