| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <efb5293f-b0ef-4c94-bf10-9ca7ebb3b53f@amd.com> Date: Fri, 14 Mar 2025 14:49:19 +0000 From: "Moger, Babu" <Babu.Moger@....com> To: "Luck, Tony" <tony.luck@...el.com> CC: Reinette Chatre <reinette.chatre@...el.com>, Peter Newman <peternewman@...gle.com>, Dave Martin <Dave.Martin@....com>, "corbet@....net" <corbet@....net>, "tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "paulmck@...nel.org" <paulmck@...nel.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "thuth@...hat.com" <thuth@...hat.com>, "rostedt@...dmis.org" <rostedt@...dmis.org>, "xiongwei.song@...driver.com" <xiongwei.song@...driver.com>, "pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>, "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>, "jpoimboe@...nel.org" <jpoimboe@...nel.org>, "Yuan, Perry" <Perry.Yuan@....com>, "Das1, Sandipan" <Sandipan.Das@....com>, "kai.huang@...el.com" <kai.huang@...el.com>, "xiaoyao.li@...el.com" <xiaoyao.li@...el.com>, "seanjc@...gle.com" <seanjc@...gle.com>, "xin3.li@...el.com" <xin3.li@...el.com>, "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>, "ebiggers@...gle.com" <ebiggers@...gle.com>, "Limonciello, Mario" <Mario.Limonciello@....com>, "james.morse@....com" <james.morse@....com>, "tan.shaopeng@...itsu.com" <tan.shaopeng@...itsu.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "maciej.wieczor-retman@...el.com" <maciej.wieczor-retman@...el.com>, "eranian@...gle.com" <eranian@...gle.com> Subject: Re: [PATCH v11 00/23] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) [AMD Official Use Only - AMD Internal Distribution Only] Hi Tony, On 3/13/2025 3:36 PM, Luck, Tony wrote: > On Thu, Mar 13, 2025 at 03:13:32PM -0500, Moger, Babu wrote: >> Hi Reinette, >> >> On 3/13/25 11:08, Reinette Chatre wrote: >>> Hi Babu, >>> >>>> #echo mbm_read_only > test/mon_data/mon_L3_00/assign_exclusive >>>> >>>> Which would result in the creation of test/mon_data/mon_L3_*/mbm_read_only >>>> >>>> So, there is not breakage of backword compatibility. >>> >>> The way I understand it I am seeing many incompatibilities. Perhaps I am missing >>> something. Could you please provide detailed steps of how first phase and >>> second phase would look? >> >> No. You didn't miss anything. I misspoke on few steps. >> >> Here are the steps. Just copying steps from Peters proposal. >> https://lore.kernel.org/lkml/CALPaoCiii0vXOF06mfV=kVLBzhfNo0SFqt4kQGwGSGVUqvr2Dg@mail.gmail.com/ >> >> >> 1. Mount the resctrl >> mount -t resctrl resctrl /sys/fs/resctrl >> >> 2. When ABMC is supported two default configurations will be created. >> >> a. info/L3_MON/counter_configs/mbm_total_bytes/event_filter >> b. info/L3_MON/counter_configs/mbm_local_bytes/event_filter >> >> These files will be populated with default total and local events >> # cat info/L3_MON/counter_configs/mbm_total_bytes/event_filter >> VictimBW >> RmtSlowFill >> RmtNTWr >> RmtFill >> LclFill >> LclNTWr >> LclSlowFill >> >> # cat info/L3_MON/counter_configs/mbm_local_bytes/event_filter >> LclFill, >> LclNTWr >> LclSlowFill >> >> 3. Users will have options to update the event configuration. >> echo LclFill > info/L3_MON/counter_configs/mbm_local_bytes/event_filter > > Once the "mkdir" support described below is implemented users will not > need to redefine these legacy event file names. That makes me happy. Yea. That is correct. > >> >> 4. As usual the events can be read from the mon_data directories. >> #mkdir /sys/fs/resctrl/test >> #cd /sys/fs/resctr/test >> #cat test/mon_data/mon_data/mon_L3_00/mbm_tota_bytes >> 101010 >> #cat test/mon_data/mon_data/mon_L3_00/mbm_local_bytes >> 32323 >> >> 5. There will be 3 files created in each group's mon_data directory when >> ABMC is supported. >> >> a. test/mon_data/mon_L3_00/assign_exclusive >> b. test/mon_data/mon_L3_00/assign_shared >> c. test/mon_data/mon_L3_00/unassign >> >> >> 6. Events can be assigned/unassigned by these commands >> >> # echo mbm_total_bytes > test/mon_data/mon_L3_00/assign_exclusive >> # echo mbm_local_bytes > test/mon_data/mon_L3_01/assign_exclusive >> # echo mbm_local_bytes > test/mon_data/mon_L3_01/unassign >> >> >> Note: >> I feel 3 files are excessive here. We can probably achieve everything in >> just one file. > > Maybe the one file could look like: > > # cat mon_L3_assignments > mbm_total_bytes: exclusive > mbm_local_bytes: shared > mbm_read_only: unassigned > > with new lines appearing when mkdir creates new events, and the obvious > write semantics: > > # echo "mbm_total_bytes: unassigned" > mon_L3_assignments > > to make updates. Yes. That would work. Also we could move the file to group's main directory like we have other files already. #cat /sys/fs/resctrl/test/mon_L3_assignments mbm_total_bytes: 0=unassigned; 1=unassigned mbm_local_bytes: 0=unassigned; 1=unassigned To assign mbm_total_bytes config on domain 0. $echo "mbm_total_bytes: 0=exclusive " > mon_L3_assignments To assign mbm_total_bytes config on all the domains. $echo "mbm_total_bytes: *=exclusive " > mon_L3_assignments #cat /sys/fs/resctrl/test/mon_L3_assignments mbm_total_bytes: 0=exclusive; 1=exclusive mbm_local_bytes: 0=unassigned; 1=unassigned > >> Not sure about mbm_assign_control interface as there are concerns with >> group listing holding the lock for long. >> >> ----------------------------------------------------------------------- >> Second phase, we can add support for "mkdir" >> >> 1. mkdir info/L3_MON/counter_configs/mbm_read_only >> >> 2. mkdir option will create "event_filter" file. >> info/L3_MON/counter_configs/mbm_read_only/event_filter >> >> 3. Users can modify event configuration. >> echo LclFill > info/L3_MON/counter_configs/mbm_read_only/event_filter >> >> 4. Users can assign the events >> >> echo mbm_read_only > test/mon_data/mon_L3_00/assign_exclusive >> >> 5. Events can be read in >> >> test/mon_data/mon_data/mon_L3_00/mbm_read_only > > Is there a matching "rmdir" to make this go away again? > I would think so. Thanks Babu
Powered by blists - more mailing lists