Some problems with reading the RTC time may happen rarely, for example
while the RTC is updating. So read the RTC many times to catch these
problems. For example, a previous attempt for my
commit ea6fa4961aab ("rtc: mc146818-lib: fix RTC presence check")
was incorrect and would have triggered this selftest.
To avoid the risk of damaging the hardware, wait 11ms before consecutive
reads.
In rtc_time_to_timestamp I copied values manually instead of casting -
just to be on the safe side. The 11ms wait period was chosen so that it is
not a divisor of 1000ms.
Signed-off-by: Mateusz Jończyk <mat.jonczyk(a)o2.pl>
Cc: Alessandro Zummo <a.zummo(a)towertech.it>
Cc: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Cc: Shuah Khan <shuah(a)kernel.org>
---
Also, before
commit cdedc45c579f ("rtc: cmos: avoid UIP when reading alarm time")
reading the RTC alarm time during RTC update produced incorrect results
on many Intel platforms. Preparing a similar selftest for this case
would be more difficult, though, because the RTC alarm time is cached by
the kernel. Direct access would have to be exposed somehow, for example
in debugfs. I may prepare a patch for it in the future.
---
tools/testing/selftests/rtc/rtctest.c | 66 +++++++++++++++++++++++++++
tools/testing/selftests/rtc/settings | 2 +-
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rtc/rtctest.c b/tools/testing/selftests/rtc/rtctest.c
index 66af608fb4c6..2b9d929a24ed 100644
--- a/tools/testing/selftests/rtc/rtctest.c
+++ b/tools/testing/selftests/rtc/rtctest.c
@@ -20,6 +20,8 @@
#define NUM_UIE 3
#define ALARM_DELTA 3
+#define READ_LOOP_DURATION_SEC 30
+#define READ_LOOP_SLEEP_MS 11
static char *rtc_file = "/dev/rtc0";
@@ -49,6 +51,70 @@ TEST_F(rtc, date_read) {
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
}
+static time_t rtc_time_to_timestamp(struct rtc_time *rtc_time)
+{
+ struct tm tm_time = {
+ .tm_sec = rtc_time->tm_sec,
+ .tm_min = rtc_time->tm_min,
+ .tm_hour = rtc_time->tm_hour,
+ .tm_mday = rtc_time->tm_mday,
+ .tm_mon = rtc_time->tm_mon,
+ .tm_year = rtc_time->tm_year,
+ };
+
+ return mktime(&tm_time);
+}
+
+static void nanosleep_with_retries(long ns)
+{
+ struct timespec req = {
+ .tv_sec = 0,
+ .tv_nsec = ns,
+ };
+ struct timespec rem;
+
+ while (nanosleep(&req, &rem) != 0) {
+ req.tv_sec = rem.tv_sec;
+ req.tv_nsec = rem.tv_nsec;
+ }
+}
+
+TEST_F_TIMEOUT(rtc, date_read_loop, READ_LOOP_DURATION_SEC + 2) {
+ int rc;
+ long iter_count = 0;
+ struct rtc_time rtc_tm;
+ time_t start_rtc_read, prev_rtc_read;
+
+ TH_LOG("Continuously reading RTC time for %ds (with %dms breaks after every read).",
+ READ_LOOP_DURATION_SEC, READ_LOOP_SLEEP_MS);
+
+ rc = ioctl(self->fd, RTC_RD_TIME, &rtc_tm);
+ ASSERT_NE(-1, rc);
+ start_rtc_read = rtc_time_to_timestamp(&rtc_tm);
+ prev_rtc_read = start_rtc_read;
+
+ do {
+ time_t rtc_read;
+
+ rc = ioctl(self->fd, RTC_RD_TIME, &rtc_tm);
+ ASSERT_NE(-1, rc);
+
+ rtc_read = rtc_time_to_timestamp(&rtc_tm);
+ /* Time should not go backwards */
+ ASSERT_LE(prev_rtc_read, rtc_read);
+ /* Time should not increase more then 1s at a time */
+ ASSERT_GE(prev_rtc_read + 1, rtc_read);
+
+ /* Sleep 11ms to avoid killing / overheating the RTC */
+ nanosleep_with_retries(READ_LOOP_SLEEP_MS * 1000000);
+
+ prev_rtc_read = rtc_read;
+ iter_count++;
+ } while (prev_rtc_read <= start_rtc_read + READ_LOOP_DURATION_SEC);
+
+ TH_LOG("Performed %ld RTC time reads.", iter_count);
+}
+
TEST_F_TIMEOUT(rtc, uie_read, NUM_UIE + 2) {
int i, rc, irq = 0;
unsigned long data;
diff --git a/tools/testing/selftests/rtc/settings b/tools/testing/selftests/rtc/settings
index a953c96aa16e..0c1a2075d5f3 100644
--- a/tools/testing/selftests/rtc/settings
+++ b/tools/testing/selftests/rtc/settings
@@ -1 +1 @@
-timeout=180
+timeout=210
--
2.25.1
Changes from Previous Version (v1)
==================================
Compared to the v1 of this patchset
(https://lore.kernel.org/linux-mm/20220223152051.22936-1-sj@kernel.org/), this
version contains below changes.
- Use __ATTR_R{O,W}_MODE() instead of __ATTR() (Greg KH)
- Change some file names for using __ATTR_R{O,W}_MODE() (Greg KH)
- Add ABI document (Greg KH)
Introduction
============
DAMON's debugfs-based user interface (DAMON_DBGFS) served very well, so far.
However, it unnecessarily depends on debugfs, while DAMON is not aimed to be
used for only debugging. Also, the interface receives multiple values via one
file. For example, schemes file receives 18 values. As a result, it is
inefficient, hard to be used, and difficult to be extended. Especially,
keeping backward compatibility of user space tools is getting only challenging.
It would be better to implement another reliable and flexible interface and
deprecate DAMON_DBGFS in long term.
For the reason, this patchset introduces a sysfs-based new user interface of
DAMON. The idea of the new interface is, using directory hierarchies and
having one dedicated file for each value. For a short example, users can do
the virtual address monitoring via the interface as below:
# cd /sys/kernel/mm/damon/admin/
# echo 1 > kdamonds/nr_kdamonds
# echo 1 > kdamonds/0/contexts/nr_contexts
# echo vaddr > kdamonds/0/contexts/0/operations
# echo 1 > kdamonds/0/contexts/0/targets/nr_targets
# echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid_target
# echo on > kdamonds/0/state
A brief representation of the files hierarchy of DAMON sysfs interface is as
below. Childs are represented with indentation, directories are having '/'
suffix, and files in each directory are separated by comma.
/sys/kernel/mm/damon/admin
│ kdamonds/nr_kdamonds
│ │ 0/state,pid
│ │ │ contexts/nr_contexts
│ │ │ │ 0/operations
│ │ │ │ │ monitoring_attrs/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ nr_regions/min,max
│ │ │ │ │ targets/nr_targets
│ │ │ │ │ │ 0/pid_target
│ │ │ │ │ │ │ regions/nr_regions
│ │ │ │ │ │ │ │ 0/start,end
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ │ schemes/nr_schemes
│ │ │ │ │ │ 0/action
│ │ │ │ │ │ │ access_pattern/
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
│ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
│ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
│ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
│ │ │ │ │ │ ...
│ │ │ │ ...
│ │ ...
Detailed usage of the files will be described in the final Documentation patch
of this patchset.
Main Difference Between DAMON_DBGFS and DAMON_SYSFS
---------------------------------------------------
At the moment, DAMON_DBGFS and DAMON_SYSFS provides same features. One
important difference between them is their exclusiveness. DAMON_DBGFS works in
an exclusive manner, so that no DAMON worker thread (kdamond) in the system can
run concurrently and interfere somehow. For the reason, DAMON_DBGFS asks users
to construct all monitoring contexts and start them at once. It's not a big
problem but makes the operation a little bit complex and unflexible.
For more flexible usage, DAMON_SYSFS moves the responsibility of preventing any
possible interference to the admins and work in a non-exclusive manner. That
is, users can configure and start contexts one by one. Note that DAMON
respects both exclusive groups and non-exclusive groups of contexts, in a
manner similar to that of reader-writer locks. That is, if any exclusive
monitoring contexts (e.g., contexts that started via DAMON_DBGFS) are running,
DAMON_SYSFS does not start new contexts, and vice versa.
Future Plan of DAMON_DBGFS Deprecation
======================================
Once this patchset is merged, DAMON_DBGFS development will be frozen. That is,
we will maintain it to work as is now so that no users will be break. But, it
will not be extended to provide any new feature of DAMON. The support will be
continued only until next LTS release. After that, we will drop DAMON_DBGFS.
User-space Tooling Compatibility
--------------------------------
As DAMON_SYSFS provides all features of DAMON_DBGFS, all user space tooling can
move to DAMON_SYSFS. As we will continue supporting DAMON_DBGFS until next LTS
kernel release, user space tools would have enough time to move to DAMON_SYSFS.
The official user space tool, damo[1], is already supporting both DAMON_SYSFS
and DAMON_DBGFS. Both correctness tests[2] and performance tests[3] of DAMON
using DAMON_SYSFS also passed.
[1] https://github.com/awslabs/damo
[2] https://github.com/awslabs/damon-tests/tree/master/corr
[3] https://github.com/awslabs/damon-tests/tree/master/perf
Complete Git Tree
=================
You can get the complete git tree from
https://git.kernel.org/sj/h/damon/sysfs/patches/v2.
Sequence of Patches
===================
First two patches (patches 1-2) make core changes for DAMON_SYSFS. The first
one (patch 1) allows non-exclusive DAMON contexts so that DAMON_SYSFS can work
in non-exclusive mode, while the second one (patch 2) adds size of DAMON enum
types so that DAMON API users can safely iterate the enums.
Third patch (patch 3) implements basic sysfs stub for virtual address spaces
monitoring. Note that this implements only sysfs files and DAMON is not
linked. Fourth patch (patch 4) links the DAMON_SYSFS to DAMON so that users
can control DAMON using the sysfs files.
Following six patches (patches 5-10) implements other DAMON features that
DAMON_DBGFS supports one by one (physical address space monitoring, DAMON-based
operation schemes, schemes quotas, schemes prioritization weights, schemes
watermarks, and schemes stats).
Following patch (patch 11) adds a simple selftest for DAMON_SYSFS, and the
final one (patch 12) documents DAMON_SYSFS.
Patch History
=============
Changes from Previous Version (v1)
==================================
Changes from v1
(https://lore.kernel.org/linux-mm/20220223152051.22936-1-sj@kernel.org/)
- Use __ATTR_R{O,W}_MODE() instead of __ATTR() (Greg KH)
- Change some file names for using __ATTR_R{O,W}_MODE() (Greg KH)
- Add ABI document (Greg KH)
Chages from RFC
(https://lore.kernel.org/linux-mm/20220217161938.8874-1-sj@kernel.org/)
- Implement all DAMON debugfs interface providing features
- Writeup documents
- Add more selftests
SeongJae Park (13):
mm/damon/core: Allow non-exclusive DAMON start/stop
mm/damon/core: Add number of each enum type values
mm/damon: Implement a minimal stub for sysfs-based DAMON interface
mm/damon/sysfs: Link DAMON for virtual address spaces monitoring
mm/damon/sysfs: Support the physical address space monitoring
mm/damon/sysfs: Support DAMON-based Operation Schemes
mm/damon/sysfs: Support DAMOS quotas
mm/damon/sysfs: Support schemes prioritization
mm/damon/sysfs: Support DAMOS watermarks
mm/damon/sysfs: Support DAMOS stats
selftests/damon: Add a test for DAMON sysfs interface
Docs/admin-guide/mm/damon/usage: Document DAMON sysfs interface
Docs/ABI/testing: Add DAMON sysfs interface ABI document
.../ABI/testing/sysfs-kernel-mm-damon | 276 ++
Documentation/admin-guide/mm/damon/usage.rst | 350 ++-
MAINTAINERS | 1 +
include/linux/damon.h | 6 +-
mm/damon/Kconfig | 7 +
mm/damon/Makefile | 1 +
mm/damon/core.c | 23 +-
mm/damon/dbgfs.c | 2 +-
mm/damon/reclaim.c | 2 +-
mm/damon/sysfs.c | 2594 +++++++++++++++++
tools/testing/selftests/damon/Makefile | 1 +
tools/testing/selftests/damon/sysfs.sh | 306 ++
12 files changed, 3552 insertions(+), 17 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-damon
create mode 100644 mm/damon/sysfs.c
create mode 100755 tools/testing/selftests/damon/sysfs.sh
--
2.17.1
Chages from Previous Version (RFC)
==================================
Compared to the RFC version of this patchset
(https://lore.kernel.org/linux-mm/20220217161938.8874-1-sj@kernel.org/), this
version contains below changes.
- Implement all DAMON debugfs interface providing features
- Writeup documents
- Add more selftests
Introduction
============
DAMON's debugfs-based user interface (DAMON_DBGFS) served very well, so far.
However, it unnecessarily depends on debugfs, while DAMON is not aimed to be
used for only debugging. Also, the interface receives multiple values via one
file. For example, schemes file receives 18 values. As a result, it is
inefficient, hard to be used, and difficult to be extended. Especially,
keeping backward compatibility of user space tools is getting only challenging.
It would be better to implement another reliable and flexible interface and
deprecate DAMON_DBGFS in long term.
For the reason, this patchset introduces a sysfs-based new user interface of
DAMON. The idea of the new interface is, using directory hierarchies and
having one dedicated file for each value. For a short example, users can do
the virtual address monitoring via the interface as below:
# cd /sys/kernel/mm/damon/admin/
# echo 1 > kdamonds/nr
# echo 1 > kdamonds/0/contexts/nr
# echo vaddr > kdamonds/0/contexts/0/operations
# echo 1 > kdamonds/0/contexts/0/targets/nr
# echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid
# echo on > kdamonds/0/state
A brief representation of the files hierarchy of DAMON sysfs interface is as
below. Childs are represented with indentation, directories are having '/'
suffix, and files in each directory are separated by comma.
/sys/kernel/mm/damon/admin
│ kdamonds/nr
│ │ 0/state,pid
│ │ │ contexts/nr
│ │ │ │ 0/operations
│ │ │ │ │ monitoring_attrs/
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ nr_regions/min,max
│ │ │ │ │ targets/nr
│ │ │ │ │ │ 0/pid
│ │ │ │ │ │ │ regions/nr
│ │ │ │ │ │ │ │ 0/start,end
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ │ schemes/nr
│ │ │ │ │ 0/action
│ │ │ │ │ │ access_pattern/
│ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ age/min,max
│ │ │ │ │ │ quotas/ms,sz,reset_interval_ms
│ │ │ │ │ │ │ weights/sz,nr_accesses,age
│ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low
│ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds
│ │ │ │ │ ...
│ │ ...
Detailed usage of the files will be described in the final Documentation patch
of this patchset.
Main Difference Between DAMON_DBGFS and DAMON_SYSFS
---------------------------------------------------
At the moment, DAMON_DBGFS and DAMON_SYSFS provides same features. One
important difference between them is their exclusiveness. DAMON_DBGFS works in
an exclusive manner, so that no DAMON worker thread (kdamond) in the system can
run concurrently and interfere somehow. For the reason, DAMON_DBGFS asks users
to construct all monitoring contexts and start them at once. It's not a big
problem but makes the operation a little bit complex and unflexible.
For more flexible usage, DAMON_SYSFS moves the responsibility of preventing any
possible interference to the admins and work in a non-exclusive manner. That
is, users can configure and start contexts one by one. Note that DAMON
respects both exclusive groups and non-exclusive groups of contexts, in a
manner similar to that of reader-writer locks. That is, if any exclusive
monitoring contexts (e.g., contexts that started via DAMON_DBGFS) are running,
DAMON_SYSFS does not start new contexts, and vice versa.
Future Plan of DAMON_DBGFS Deprecation
======================================
Once this patchset is merged, DAMON_DBGFS development will be frozen. That is,
we will maintain it to work as is now so that no users will be break. But, it
will not be extended to provide any new feature of DAMON. The support will be
continued only until next LTS release. After that, we will drop DAMON_DBGFS.
User-space Tooling Compatibility
--------------------------------
As DAMON_SYSFS provides all features of DAMON_DBGFS, all user space tooling can
move to DAMON_SYSFS. As we will continue supporting DAMON_DBGFS until next LTS
kernel release, user space tools would have enough time to move to DAMON_SYSFS.
The official user space tool, damo[1], is already supporting both DAMON_SYSFS
and DAMON_DBGFS. Both correctness tests[2] and performance tests[3] of DAMON
using DAMON_SYSFS also passed.
[1] https://github.com/awslabs/damo
[2] https://github.com/awslabs/damon-tests/tree/master/corr
[3] https://github.com/awslabs/damon-tests/tree/master/perf
Complete Git Tree
=================
You can get the complete git tree from
https://git.kernel.org/sj/h/damon/sysfs/patches/v1.
Sequence of Patches
===================
First two patches (patches 1-2) make core changes for DAMON_SYSFS. The first
one (patch 1) allows non-exclusive DAMON contexts so that DAMON_SYSFS can work
in non-exclusive mode, while the second one (patch 2) adds size of DAMON enum
types so that DAMON API users can safely iterate the enums.
Third patch (patch 3) implements basic sysfs stub for virtual address spaces
monitoring. Note that this implements only sysfs files and DAMON is not
linked. Fourth patch (patch 4) links the DAMON_SYSFS to DAMON so that users
can control DAMON using the sysfs files.
Following six patches (patches 5-10) implements other DAMON features that
DAMON_DBGFS supports one by one (physical address space monitoring, DAMON-based
operation schemes, schemes quotas, schemes prioritization weights, schemes
watermarks, and schemes stats).
Following patch (patch 11) adds a simple selftest for DAMON_SYSFS, and the
final one (patch 12) documents DAMON_SYSFS.
SeongJae Park (12):
mm/damon/core: Allow non-exclusive DAMON start/stop
mm/damon/core: Add number of each enum type values
mm/damon: Implement a minimal stub for sysfs-based DAMON interface
mm/damon/sysfs: Link DAMON for virtual address spaces monitoring
mm/damon/sysfs: Support physical address space monitoring
mm/damon/sysfs: Support DAMON-based Operation Schemes
mm/damon/sysfs: Support DAMOS quotas
mm/damon/sysfs: Support schemes prioritization weights
mm/damon/sysfs: Support DAMOS watermarks
mm/damon/sysfs: Support DAMOS stats
selftests/damon: Add a test for DAMON sysfs interface
Docs/admin-guide/mm/damon/usage: Document DAMON sysfs interface
Documentation/admin-guide/mm/damon/usage.rst | 349 ++-
include/linux/damon.h | 6 +-
mm/damon/Kconfig | 7 +
mm/damon/Makefile | 1 +
mm/damon/core.c | 23 +-
mm/damon/dbgfs.c | 2 +-
mm/damon/reclaim.c | 2 +-
mm/damon/sysfs.c | 2684 ++++++++++++++++++
tools/testing/selftests/damon/Makefile | 1 +
tools/testing/selftests/damon/sysfs.sh | 306 ++
10 files changed, 3364 insertions(+), 17 deletions(-)
create mode 100644 mm/damon/sysfs.c
create mode 100755 tools/testing/selftests/damon/sysfs.sh
--
2.17.1
Dzień dobry,
dostrzegam możliwość współpracy z Państwa firmą.
Świadczymy kompleksową obsługę inwestycji w fotowoltaikę, która obniża koszty energii elektrycznej nawet o 90%.
Czy są Państwo zainteresowani weryfikacją wstępnych propozycji?
Pozdrawiam,
Jakub Daroch