LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 09-11-2018, 12:07 PM   #91
RadicalDreamer
Senior Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 1,154

Rep: Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565

Quote:
Originally Posted by abga View Post
As I understand it, your relative's CPU is "a bit unstable" and has "poor cooling". Setting the governor on performance should not be persistent after a reboot, I can't follow your situation there.
How did you set it ondemand? Have you blacklisted the intel_pstate driver providing the kernel boot parameter intel_pstate=disable ?
After trying out the new rc.cpufreq on the machine in question and after experiencing instability I looked at what the cores were doing. I noticed at least one core was running hard all the time (I let it run for 5-10 minutes and checked the sensors temperatures occasionally) with just Plasma 5, xterm and Firefox open. cpufreq-info said one core at least was 4 GHZ and sensors said its temperature was 66 C. I then edited rc.cpufreq and put ondemand where performance was in the SCALING_GOVERNOR under the intel_pstate related if statement. Then rebooted and haven't had problems since.

I think instead of messing with governor speeds it would be a better option to up the min frequencies on intel processors with something like (max+min)/2. For my relatives needs they don't need "performance" at all. The instability is with the computer itself. My concern with "performance" is that one CPU core stayed at 4 GHZ and went to 66 C with fan cooling and the computer wasn't doing anything to warrant it.

Last edited by RadicalDreamer; 09-11-2018 at 12:09 PM.
 
1 members found this post helpful.
Old 09-11-2018, 12:45 PM   #92
gegechris99
Member
 
Registered: Oct 2005
Location: France
Distribution: Slackware current 64bit
Posts: 977
Blog Entries: 5

Rep: Reputation: 191Reputation: 191
In post 71, abga proposed changes to upsteam scripts (/etc/rc.d/rc.cpufreq and /etc/acpi/acpi_handler.sh) to handle two situations:

#1: "if the computer starts on batteries, then the CPU PM governor should be set on powersave"
#2: "after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events."

For case #1, I think something in /etc/rc.d/rc.local is manageable. I could make a proposal in a later post.

Here, I would like to share my suggestion to manage case #2 without any change to /etc/acpi/acpi_handler.sh. This approach has the benefit of not forcing everybody to adopt the proposed changes.

Reference:
https://wiki.archlinux.org/index.php..._configuration

I created a separate acpi event file and its associated handler script:

event file: /etc/acpi/events/ac_adapter_events
Code:
# Pass AC adapter events to one handler script
event=ac_adapter*
action=/etc/acpi/ac_adapter_handler.sh %e
handler file: /etc/acpi/ac_adapter_handler.sh
Code:
#!/bin/sh
# acpi handler for AC adapter events

IFS=${IFS}/
set $@

case "$2" in
  AC*|AD*)
     case "$4" in
       00000000)
         if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then
           echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
           logger "AC Power not available, setting CPU frequency scaling governor:  $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"
         fi
       ;;
       00000001)
         if [ -r /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ]; then
           if grep -q "ondemand" /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors; then
             echo "ondemand" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
           else
             echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 1> /dev/null 2> /dev/null
           fi
           logger "AC Power available, setting CPU frequency scaling governor:  $(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor)"
         fi
       ;;
     esac
     ;;
  *) logger "ACPI action undefined: $2"
     ;;
esac
Then made /etc/acpi/ac_adapter_handler.sh executable and restarted acpid
Code:
chmod +x /etc/acpi/ac_adapter_handler.sh
/etc/rc.d/rc.acpid restart
This approach works on my Slackware64 14.2

Credit goes to abga for stoking my interest in this topic. Thanks.

Last edited by gegechris99; 09-11-2018 at 01:59 PM. Reason: typo
 
2 members found this post helpful.
Old 09-11-2018, 01:26 PM   #93
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,601

Rep: Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887
Quote:
Originally Posted by RadicalDreamer View Post
After trying out the new rc.cpufreq on the machine in question and after experiencing instability I looked at what the cores were doing. I noticed at least one core was running hard all the time (I let it run for 5-10 minutes and checked the sensors temperatures occasionally) with just Plasma 5, xterm and Firefox open. cpufreq-info said one core at least was 4 GHZ and sensors said its temperature was 66 C. I then edited rc.cpufreq and put ondemand where performance was in the SCALING_GOVERNOR under the intel_pstate related if statement. Then rebooted and haven't had problems since.

I think instead of messing with governor speeds it would be a better option to up the min frequencies on intel processors with something like (max+min)/2. For my relatives needs they don't need "performance" at all. The instability is with the computer itself. My concern with "performance" is that one CPU core stayed at 4 GHZ and went to 66 C with fan cooling and the computer wasn't doing anything to warrant it.
First, just to clear some misunderstandings(again). If you're using a modern Intel CPU, starting with the Sandy Brdige architecture, the kernel will load the intel_pstate driver for the CPU PM. This driver does only support two governors, powersave (default) and performance. If you don't like the performance governor then your only other option is powersave, nothing else will be accepted by the intel_pstate driver. If you push the ondemand governor, like you did, the intel_pstate driver will ignore that and will use its default powersave governor instead.
Code:
 
# check what PM driver you're currently using
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
# check what governor is currently active
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
On your Skylake 6700K observations and issue, following the tests I ran, I can also confirm that with the governor set on performance, the CPU is keeping its core frequencies maxed out but had no problem with that, other than a slight increase in temperature. The temperature you reported (66 C) shouldn't be a concern and the reported frequency (4 GHz) is also not a problem (factory specs).
Don't know why are you experiencing the instability and would suggest:
- check your BIOS and disable any overclocking config (if any)
- make sure that the heatsink&fan combo is not applying too much pressure on the CPU
https://www.pcgamer.com/intel-skylak...-some-coolers/
- get the latest BIOS / microcode for the CPU:
https://en.wikipedia.org/wiki/Skylak...)#Known_issues
https://www.pcworld.com/article/3021...ylake-bug.html

I'd still support the choice of setting the governor on performance for intel_pstate and considering your feedback useful but your issue an isolated case that might be the result of some other causes.
 
1 members found this post helpful.
Old 09-11-2018, 01:51 PM   #94
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,773
Blog Entries: 2

Rep: Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509
Thumbs up

Quote:
Originally Posted by aaditya View Post
Thank you for your kind words, kjhambrick :-)

I have been lurking around too, this thread has been very informative.

Using TLP for more than 3 years now without noticing any adverse effects. Here are some defaults from its config file:

Code:
# Set CPU performance versus energy savings policy:
#   performance, balance-performance, default, balance-power, power.
# Values are given in order of increasing power saving.
# Requires kernel module msr and x86_energy_perf_policy from linux-tools.
ENERGY_PERF_POLICY_ON_AC=performance
ENERGY_PERF_POLICY_ON_BAT=power

# Disk devices; separate multiple devices with spaces (default: sda).
# Devices can be specified by disk ID also (lookup with: tlp diskid).
DISK_DEVICES="sda sdb"

# Disk advanced power management level: 1..254, 255 (max saving, min, off).
# Levels 1..127 may spin down the disk; 255 allowable on most drives.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"

# Hard disk spin down timeout:
#   0:        spin down disabled
#   1..240:   timeouts from 5s to 20min (in units of 5s)
#   241..251: timeouts from 30min to 5.5 hours (in units of 30min)
# See 'man hdparm' for details.
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the hardware default for the particular disk.
#DISK_SPINDOWN_TIMEOUT_ON_AC="0 0"
#DISK_SPINDOWN_TIMEOUT_ON_BAT="0 0"

# Select IO scheduler for the disk devices: cfq, deadline, noop (Default: cfq).
# Separate values for multiple disks with spaces. Use the special value 'keep'
# to keep the kernel default scheduler for the particular disk.
#DISK_IOSCHED="cfq cfq"

# AHCI link power management (ALPM) for disk devices:
#   min_power, med_power_with_dipm(*), medium_power, max_performance.
# (*) Kernel >= 4.15 required, then recommended.
# Multiple values separated with spaces are tried sequentially until success.
SATA_LINKPWR_ON_AC="med_power_with_dipm max_performance"
SATA_LINKPWR_ON_BAT="med_power_with_dipm min_power"
With the default config laptop is responsive even on battery, with increase in battery life of around 1.5 hours.

YMMV.

P.S.
powertop can be used to check power consumption and tunables.

Edit-
https://linrunner.de/en/tlp/docs/tlp-faq.html
Code:
bash-4.3# /etc/rc.d/rc.tlp status
--- TLP 1.1 --------------------------------------------

+++ System Info
System         = FUJITSU 10601409549 LIFEBOOK T901
BIOS           = Version 1.15
Kernel         = 4.18.6 #1 SMP Wed Sep 5 07:29:56 UTC 2018 x86_64
/proc/cmdline  = \\boot\vmlinuz-generic-4.18.6 root=/dev/sda2 vt.default_utf8=1 vga=normal ro 4 spec_store_bypass_disable=on ro initrd=boot\initrd-4.18.6.gz
Init system    = sysvinit
Boot mode      = UEFI

+++ TLP Status
State          = enabled
Last run       = 08:44:20 PM,     35 sec(s) ago
Mode           = battery
Power source   = battery

bash-4.3#
since the first days of using it - looking good
 
1 members found this post helpful.
Old 09-11-2018, 02:05 PM   #95
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,601

Rep: Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887
Quote:
Originally Posted by gegechris99 View Post
abga proposed changes to upsteam scripts (/etc/rc.d/rc.cpufreq and /etc/acpi/acpi_handler.sh) to handle two situations:

#1: "if the computer starts on batteries, then the CPU PM governor should be set on powersave"
#2: "after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events."

For case #1, I think something in /etc/rc.d/rc.local is manageable. I could make a proposal in a later post.
Actually I was only focusing on one goal, to set the governor on powersave if running on batteries and only change it to ondemand/performance if the AC adapter is connected. The 2 solutions for the 2 "situations" I described should be taken always together, as they're part of the same unique goal. I might have used some confusing wording and I apologize for that, not a native English speaker myself.
I made use of /etc/rc.d/rc.cpufreq for checking if the system was booted on batteries just for completing the goal and complementing acpid. acpid is not useful if there's no event happening and booting on batteries is an "event" that acpid, which is started later in the boot process, doesn't care about.

Your approach, isolating the ac_adapter* event and using a dedicated script for handling it, is interesting and as you said appropriate for users who might want to opt out. In your case, this needs to be documented, otherwise nobody will know about it.

I doubt that the changes I/you proposed will ever make their way upstream and I'm sorry now for not opening a new thread for this particular CPU PM improvement proposal. I was caught in the feedback "frenzy" and started to look for a solution, found one and documented it in post #71.

Last edited by abga; 09-11-2018 at 02:09 PM. Reason: formatting
 
Old 09-11-2018, 08:18 PM   #96
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 334

Rep: Reputation: Disabled
Quote:
Originally Posted by gegechris99 View Post
In post 71, abga proposed changes to upsteam scripts (/etc/rc.d/rc.cpufreq and /etc/acpi/acpi_handler.sh) to handle two situations:

#1: "if the computer starts on batteries, then the CPU PM governor should be set on powersave"
#2: "after finishing the boot process and acpid is running, automatically switching the CPU PM governor based on running on AC Power connect/disconnect events."
Regarding #1, I would suggest the opposite. Even if the computer boots on batteries, there could be spinning platters drawing power. I propose to boot the kernel as quickly as possible via "performance", then switch to "ondemand" or "powersave" once /sbin/init launches the /etc/rc.d scripts.

If there's a need to tune the HD power parameters (spin-down time, swap tuning, FS flushing), the adjustment(s) can be handled in rc.local. But by booting with "performance", the system launches rc.local sooner after boot.

Of course, this can be proven or invalidated by someone using a Kill-A-Watt. Any volunteers?
 
Old 09-12-2018, 05:37 AM   #97
RadicalDreamer
Senior Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 1,154

Rep: Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565
Quote:
Originally Posted by abga View Post
I'd still support the choice of setting the governor on performance for intel_pstate and considering your feedback useful but your issue an isolated case that might be the result of some other causes.
I thought ondemand was setting things to powersave but I wasn't sure. It acts like ondemand. I put 4K video on or a game and some processors jump 2 GHZ. I'm sorry that I made you explain that "again." Thanks for the links. I've been at a lost as to why the system all of sudden decided to hate Windows after 2 years. I've ran stress tests until the processor got real hot. The system is stable in Safe Mode in Windows 7.

I disagree with having a core running on max all the time. I wish there was a setting between powersave and performance like in Windows. One called "Balanced."
 
Old 09-12-2018, 05:46 AM   #98
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,727

Rep: Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741Reputation: 741
if anyone thinks that a system is/feels snappier when surfing the web, using office, compiling packages, I would say: welcome to the world of imaginations and placebos

we still have no use case where this makes a measurable difference, and where an average user has some benefit.
therefore heating CPUs, == more power consumption, and higher noise through fans.

Win for the user: microsecond on synthetic benchmarks, so nothing at all. A bad deal. except you want to heat your home this way.

Adding this change to Slackware was a failure, it just makes the time to a useful system longer because now there is one more additional fix to remember and to do.
 
1 members found this post helpful.
Old 09-12-2018, 09:18 AM   #99
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,601

Rep: Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887
Quote:
Originally Posted by RadicalDreamer View Post
I thought ondemand was setting things to powersave but I wasn't sure. It acts like ondemand. I put 4K video on or a game and some processors jump 2 GHZ. I'm sorry that I made you explain that "again." Thanks for the links. I've been at a lost as to why the system all of sudden decided to hate Windows after 2 years. I've ran stress tests until the processor got real hot. The system is stable in Safe Mode in Windows 7.

I disagree with having a core running on max all the time. I wish there was a setting between powersave and performance like in Windows. One called "Balanced."
You don't need to be sorry, the improper use of the ondemand governor for Intel based systems that are using the intel_pstate driver is the subject of this thread and it was described in every second/third post.
The powersave governor is also acting well once you start some (continuous) processes and the CPU is awake, that was never an issue, the issue (lagginess) starts to be evident when you do some tasks sporadically, that's browsing through the DE menus, browsing the internet, issuing some commands in the console, etc. And this might be more evident on low/medium-end CPUs and not on your high-end 6700K.
I said already that I don't understand what's wrong with your system and provided you with some hints. Setting the governor on performance should not cause any trouble after your restart your computer because this is a driver and its settings should not remain persistent.

You can always set your governor on powersave if you don't like keeping one core at its max frequency. This is a limitation of the intel_pstate driver, Intel should fix this, and again, the very subject of this thread.
 
Old 09-12-2018, 11:12 AM   #100
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,601

Rep: Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887Reputation: 887
Quote:
Originally Posted by a4z View Post
if anyone thinks that a system is/feels snappier when surfing the web, using office, compiling packages, I would say: welcome to the world of imaginations and placebos

we still have no use case where this makes a measurable difference, and where an average user has some benefit.
therefore heating CPUs, == more power consumption, and higher noise through fans.

Win for the user: microsecond on synthetic benchmarks, so nothing at all. A bad deal. except you want to heat your home this way.

Adding this change to Slackware was a failure, it just makes the time to a useful system longer because now there is one more additional fix to remember and to do.
Personally, I'm sure about experiencing the ramp-up lagginess, confirmed observations on 3 different systems (laptops) and you can also take a look over this imaginative and placebo biased graph:
https://www.phoronix.com/scan.php?pa...linux315&num=6
You can always choose your preferred governor:
https://www.linuxquestions.org/quest...ml#post5898048
And you can always take care about the CPU power consumption on your mobile device, pretty easy:
https://www.linuxquestions.org/quest...ml#post5901577
 
Old 09-12-2018, 02:08 PM   #101
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,773
Blog Entries: 2

Rep: Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509Reputation: 509
Using the 4.18.x for a week now (our unofficial build).

I'm amused how this does not apply to the 4.18.x as it does to the 4.4.x series Slackware 14.2 still supports.

Amusing dead horse racing
 
1 members found this post helpful.
Old 09-12-2018, 02:22 PM   #102
RadicalDreamer
Senior Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 1,154

Rep: Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565
Quote:
Originally Posted by abga View Post
You don't need to be sorry, the improper use of the ondemand governor for Intel based systems that are using the intel_pstate driver is the subject of this thread and it was described in every second/third post.
The powersave governor is also acting well once you start some (continuous) processes and the CPU is awake, that was never an issue, the issue (lagginess) starts to be evident when you do some tasks sporadically, that's browsing through the DE menus, browsing the internet, issuing some commands in the console, etc. And this might be more evident on low/medium-end CPUs and not on your high-end 6700K.
I said already that I don't understand what's wrong with your system and provided you with some hints. Setting the governor on performance should not cause any trouble after your restart your computer because this is a driver and its settings should not remain persistent.

You can always set your governor on powersave if you don't like keeping one core at its max frequency. This is a limitation of the intel_pstate driver, Intel should fix this, and again, the very subject of this thread.
It caused problems with the computer in question after I restarted the computer twice but that computer has serious problems anyway. Performance setting triggered it. So Slackware should cater to low/medium-end CPUs with adequate cooling? I think upping the min freq would make more sense for these older computers. That is what I'll do when the time comes:
Quote:
Change min_perf_pct and max_perf_pct.

As root: echo XX > /sys/devices/system/cpu/intel_pstate/min_perf_pct (and max_perf_pct obviously)
XX being the percentage to which the frequency goes up to, relative to maximum frequency.
https://www.phoronix.com/forums/foru...nux-3-15/page2

This makes sense because what min_perf_pct does is multiply the max frequency with the percentage selected. My max is 3.9 GHZ. min_perf_pct is set to 41 so my min freq is 1.6 GHZ which it is. I set it to 50 and my min freq for all cores is now 2.00 GHZ.

I guess each to their own but I don't think a core should be going full blast all the time. There has to be a better way to do this. I don't think Slackware should be shipping with this but it is our BDFL's decision. If the min frequencies isn't good enough then up it by a percentage is my answer to the performance problem. At least I figured out my solution to keeping my aging hardware relevant.
https://www.kernel.org/doc/html/v4.1...el_pstate.html
 
Old 09-12-2018, 02:24 PM   #103
RadicalDreamer
Senior Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 1,154

Rep: Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565
Quote:
Originally Posted by SCerovec View Post
Using the 4.18.x for a week now (our unofficial build).

I'm amused how this does not apply to the 4.18.x as it does to the 4.4.x series Slackware 14.2 still supports.

Amusing dead horse racing
What do you mean?
 
Old 09-12-2018, 02:27 PM   #104
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1243Reputation: 1243Reputation: 1243Reputation: 1243Reputation: 1243Reputation: 1243Reputation: 1243Reputation: 1243Reputation: 1243
Probably he wants to says that that Intel CPUs works happily with "ondemand" governor under 4.18.x and later, then this entire thread is a dead horse racing.

Last edited by Darth Vader; 09-12-2018 at 02:29 PM.
 
1 members found this post helpful.
Old 09-12-2018, 02:32 PM   #105
RadicalDreamer
Senior Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 1,154

Rep: Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565Reputation: 565
Quote:
Originally Posted by Darth Vader View Post
Probably he wants to says that that Intel CPUs works happily with "ondemand" governor under 4.18.x and later, then this entire thread is a dead horse racing.
I was thinking that too but I want confirmation!
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
CPU frequency governor configuration yanf81 Linux - Software 12 11-15-2015 12:03 PM
LXer: Samsung Introduces "LAB" Linux Frequency Governor LXer Syndicated Linux News 0 04-10-2013 04:31 AM
[SOLVED] compiz fusion " cpu frequency scaling unsupported" mad11 Linux - Newbie 0 03-19-2010 07:10 AM
[SOLVED] Using the "powersave" governor on battery and "ondemand" governor on AC power piratesmack Slackware 5 01-21-2010 12:54 PM
"CPU frequency is not supported and system is very very slow" kandhakumar Linux - General 3 06-29-2008 06:25 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:39 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration