<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in .kunitconfig</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>0fc8f6200d2313278fbf4539bbab74677c685531 - Merge drm/drm-fixes into drm-misc-fixes</title>
        <link>http://kernelsources.org:8080/source/history/linux/kernel/time/.kunitconfig#0fc8f6200d2313278fbf4539bbab74677c685531</link>
        <description>Merge drm/drm-fixes into drm-misc-fixesGetting fixes and updates from v7.1-rc1.Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;

            List of files:
            /linux/kernel/time/.kunitconfig</description>
        <pubDate>Mon, 27 Apr 2026 10:26:49 +0200</pubDate>
        <dc:creator>Thomas Zimmermann &lt;tzimmermann@suse.de&gt;</dc:creator>
    </item>
<item>
        <title>c1fe867b5bf9c57ab7856486d342720e2b205eed - Merge tag &apos;timers-core-2026-04-12&apos; of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
        <link>http://kernelsources.org:8080/source/history/linux/kernel/time/.kunitconfig#c1fe867b5bf9c57ab7856486d342720e2b205eed</link>
        <description>Merge tag &apos;timers-core-2026-04-12&apos; of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipPull timer core updates from Thomas Gleixner: - A rework of the hrtimer subsystem to reduce the overhead for   frequently armed timers, especially the hrtick scheduler timer:     - Better timer locality decision     - Simplification of the evaluation of the first expiry time by       keeping track of the neighbor timers in the RB-tree by providing       a RB-tree variant with neighbor links. That avoids walking the       RB-tree on removal to find the next expiry time, but even more       important allows to quickly evaluate whether a timer which is       rearmed changes the position in the RB-tree with the modified       expiry time or not. If not, the dequeue/enqueue sequence which       both can end up in rebalancing can be completely avoided.     - Deferred reprogramming of the underlying clock event device. This       optimizes for the situation where a hrtimer callback sets the       need resched bit. In that case the code attempts to defer the       re-programming of the clock event device up to the point where       the scheduler has picked the next task and has the next hrtick       timer armed. In case that there is no immediate reschedule or       soft interrupts have to be handled before reaching the reschedule       point in the interrupt entry code the clock event is reprogrammed       in one of those code paths to prevent that the timer becomes       stale.     - Support for clocksource coupled clockevents       The TSC deadline timer is coupled to the TSC. The next event is       programmed in TSC time. Currently this is done by converting the       CLOCK_MONOTONIC based expiry value into a relative timeout,       converting it into TSC ticks, reading the TSC adding the delta       ticks and writing the deadline MSR.       As the timekeeping core has the conversion factors for the TSC       already, the whole back and forth conversion can be completely       avoided. The timekeeping core calculates the reverse conversion       factors from nanoseconds to TSC ticks and utilizes the base       timestamps of TSC and CLOCK_MONOTONIC which are updated once per       tick. This allows a direct conversion into the TSC deadline value       without reading the time and as a bonus keeps the deadline       conversion in sync with the TSC conversion factors, which are       updated by adjtimex() on systems with NTP/PTP enabled.     - Allow inlining of the clocksource read and clockevent write       functions when they are tiny enough, e.g. on x86 RDTSC and WRMSR.   With all those enhancements in place a hrtick enabled scheduler   provides the same performance as without hrtick. But also other   hrtimer users obviously benefit from these optimizations. - Robustness improvements and cleanups of historical sins in the   hrtimer and timekeeping code. - Rewrite of the clocksource watchdog.   The clocksource watchdog code has over time reached the state of an   impenetrable maze of duct tape and staples. The original design,   which was made in the context of systems far smaller than today, is   based on the assumption that the to be monitored clocksource (TSC)   can be trivially compared against a known to be stable clocksource   (HPET/ACPI-PM timer).   Over the years this rather naive approach turned out to have major   flaws. Long delays between the watchdog invocations can cause wrap   arounds of the reference clocksource. The access to the reference   clocksource degrades on large multi-sockets systems dure to   interconnect congestion. This has been addressed with various   heuristics which degraded the accuracy of the watchdog to the point   that it fails to detect actual TSC problems on older hardware which   exposes slow inter CPU drifts due to firmware manipulating the TSC to   hide SMI time.   The rewrite addresses this by:     - Restricting the validation against the reference clocksource to       the boot CPU which is usually closest to the legacy block which       contains the reference clocksource (HPET/ACPI-PM).     - Do a round robin validation betwen the boot CPU and the other       CPUs based only on the TSC with an algorithm similar to the TSC       synchronization code during CPU hotplug.     - Being more leniant versus remote timeouts - The usual tiny fixes, cleanups and enhancements all over the place* tag &apos;timers-core-2026-04-12&apos; of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (75 commits)  alarmtimer: Access timerqueue node under lock in suspend  hrtimer: Fix incorrect #endif comment for BITS_PER_LONG check  posix-timers: Fix stale function name in comment  timers: Get this_cpu once while clearing the idle state  clocksource: Rewrite watchdog code completely  clocksource: Don&apos;t use non-continuous clocksources as watchdog  x86/tsc: Handle CLOCK_SOURCE_VALID_FOR_HRES correctly  MIPS: Don&apos;t select CLOCKSOURCE_WATCHDOG  parisc: Remove unused clocksource flags  hrtimer: Add a helper to retrieve a hrtimer from its timerqueue node  hrtimer: Remove trailing comma after HRTIMER_MAX_CLOCK_BASES  hrtimer: Mark index and clockid of clock base as const  hrtimer: Drop unnecessary pointer indirection in hrtimer_expire_entry event  hrtimer: Drop spurious space in &apos;enum hrtimer_base_type&apos;  hrtimer: Don&apos;t zero-initialize ret in hrtimer_nanosleep()  hrtimer: Remove hrtimer_get_expires_ns()  timekeeping: Mark offsets array as const  timekeeping/auxclock: Consistently use raw timekeeper for tk_setup_internals()  timer_list: Print offset as signed integer  tracing: Use explicit array size instead of sentinel elements in symbol printing  ...

            List of files:
            /linux/kernel/time/.kunitconfig</description>
        <pubDate>Tue, 14 Apr 2026 19:27:07 +0200</pubDate>
        <dc:creator>Linus Torvalds &lt;torvalds@linux-foundation.org&gt;</dc:creator>
    </item>
<item>
        <title>bc47b2e823914966c15a09422f8fc3aa98d34c1b - time/kunit: Add .kunitconfig</title>
        <link>http://kernelsources.org:8080/source/history/linux/kernel/time/.kunitconfig#bc47b2e823914966c15a09422f8fc3aa98d34c1b</link>
        <description>time/kunit: Add .kunitconfigAdd .kunitconfig file to the time directory to enable easy execution ofKUnit tests.With the .kunitconfig, developers can run the tests:  $ ./tools/testing/kunit/kunit.py run --kunitconfig kernel/timeAlso, add the new .kunitconfig file to the TIMEKEEPING section in theMAINTAINERS file.Signed-off-by: Ryota Sakamoto &lt;sakamo.ryota@gmail.com&gt;Signed-off-by: Thomas Gleixner &lt;tglx@kernel.org&gt;Link: https://patch.msgid.link/20260223-add-time-kunitconfig-v1-1-1801eeb33ece@gmail.com

            List of files:
            /linux/kernel/time/.kunitconfig</description>
        <pubDate>Mon, 23 Feb 2026 07:23:24 +0100</pubDate>
        <dc:creator>Ryota Sakamoto &lt;sakamo.ryota@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
