https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4186 Lustre <p>lustre_get_jobid is calling cfs_access_process_vm() that is a core mm function. In upstream kernel client, we changed it to read jobid variable from /proc/self/environ file and cache it in lu_env so that we can remove cfs_access_process_vm().</p> <p>Currently, jobid is cached at vvp layer and is only accessible by llite. One possible optimization is to add a new lu_context_key at obdclass layer to cache jobid. And then change lustre_get_jobid() to handle the caching logic. For every thread, it only read proc environ file once and cache the results forever. Callers just call lustre_get_jobid() and use the result thereafter.</p> <p>The ticket is created to back port related upstream kernel patches and also initiate the discussion about whether it is good to cache jobid in lu_env at obdclass layer.</p> LU-4186

Change lustre_get_jobid to read from proc file and cache it in lu_env

Improvement Minor Resolved Duplicate WC Triage Peng Tao Wed, 30 Oct 2013 02:38:56 +0000 Mon, 24 Apr 2023 18:52:24 +0000 Mon, 24 Apr 2023 18:52:24 +0000 0 5 <p>We'd like to be able to fetch the jobid for a thread once from the environment (which has just gotten more expensive in the upstream kernel), and then keep it in a thread-local location afterward that can be accessed easily.</p> <p>The jobid should track IO operations associated with the user process, and not against processes like ptlrpcd or pdflush, so we also store it in the inode for use when RPCs are generated. </p> <p>Is lu_env the right place for this to go? How can it be used so that the jobid is accessible in different layers of the stack?</p> <p>It turns out that Greg KH has explicitly rejected the parsing-proc approach. As a result, it is no longer necessary to discuss where to cache jobid... Although I am still uncertain what to do with cfs_access_process_vm().</p> <p>I'm not against caching the jobid in lu_env as was done in your first patch, since that is still more efficient than looking it up for each syscall. </p> <p>For now, I don't really care if the upstream build is disabled for the architectures that don't have copy_to_user_page() available. That was actually fixed for MIPS, so it could be enabled separate from the others, but I'd rather just drop this issue for now or Greg may just ask to get all of jobid deleted. I don't want the in-kernel client to be crippled for foolish reasons like this. </p> Duplicate LU-12330 Development Rank 1|hzw7an: Rank (Obsolete) 11326