* cpuidle status in mainline for Beagleboard xM
@ 2011-09-01 14:14 javier Martin
2011-09-01 15:10 ` Kevin Hilman
0 siblings, 1 reply; 9+ messages in thread
From: javier Martin @ 2011-09-01 14:14 UTC (permalink / raw)
To: linux-omap; +Cc: Koen Kooi
Hi,
I am trying to enable cpuidle and cpufreq support in latest stable
kernel (3.0.4) in the Beagleboard xM.
The default governor I've selected in the kernel menu is "powersave".
However, when I execute powertop 1.12 (downloaded from Angstrom 2010.x
repository through opkg) I get the following:
Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0.4%)
C0 16.7ms (99.6%)
C1 0.0ms ( 0.0%)
C2 0.0ms ( 0.0%)
C3 0.0ms ( 0.0%)
C4 0.0ms ( 0.0%)
C5 0.0ms ( 0.0%)
C6 0.0ms ( 0.0%)
So, the CPU always stays in C0 status and P-states are not shown. I've
read some old reports of this working properly in omap-pm-next branch
http://groups.google.com/group/beagleboard/browse_thread/thread/b03e08868af7c6e0?pli=1%29
Do cpuidle and cpufreq really work in mainline?
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-01 14:14 cpuidle status in mainline for Beagleboard xM javier Martin
@ 2011-09-01 15:10 ` Kevin Hilman
2011-09-01 15:33 ` javier Martin
0 siblings, 1 reply; 9+ messages in thread
From: Kevin Hilman @ 2011-09-01 15:10 UTC (permalink / raw)
To: javier Martin; +Cc: linux-omap, Koen Kooi
javier Martin <javier.martin@vista-silicon.com> writes:
> I am trying to enable cpuidle and cpufreq support in latest stable
> kernel (3.0.4) in the Beagleboard xM.
OMAP CPUfreq driver is still not in mailine. I plan to rectify that
(finally) for v3.2. In the mean time, feel free to try the
pm-wip/cpufreq branch from my linux-omap-pm tree[1] (currently based on
v3.0-rc3)
> The default governor I've selected in the kernel menu is "powersave".
> However, when I execute powertop 1.12 (downloaded from Angstrom 2010.x
> repository through opkg) I get the following:
>
>
> Cn Avg residency P-states (frequencies)
> C0 (cpu running) ( 0.4%)
> C0 16.7ms (99.6%)
> C1 0.0ms ( 0.0%)
> C2 0.0ms ( 0.0%)
> C3 0.0ms ( 0.0%)
> C4 0.0ms ( 0.0%)
> C5 0.0ms ( 0.0%)
> C6 0.0ms ( 0.0%)
>
> So, the CPU always stays in C0 status and P-states are not shown.
P-states are not shown because there is no CPUfreq driver, so no
P-states available, and of course the choice of CPUfreq governor doesn't
matter.
CPU is staying in C0 probably because UARTs are not being idled, so SoC
cannot hit deeper idle states. Try the following at the command line to
to enable UART idle timeouts, so the SoC can attempt idle after the
timeout period
# UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
After 5 seconds of inactivity on the UARTs, you should see the SoC
hitting deeper C-states.
Kevin
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-01 15:10 ` Kevin Hilman
@ 2011-09-01 15:33 ` javier Martin
2011-09-01 17:46 ` Kevin Hilman
0 siblings, 1 reply; 9+ messages in thread
From: javier Martin @ 2011-09-01 15:33 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, Koen Kooi
Hi Kevin,
thanks for your help.
> CPU is staying in C0 probably because UARTs are not being idled, so SoC
> cannot hit deeper idle states. Try the following at the command line to
> to enable UART idle timeouts, so the SoC can attempt idle after the
> timeout period
>
> # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
> echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> After 5 seconds of inactivity on the UARTs, you should see the SoC
> hitting deeper C-states.
I've tried that but it still doesn't hit any C-state deeper than 0.
I'll try the same test using your pm branch you pointed me out and
post the results.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-01 15:33 ` javier Martin
@ 2011-09-01 17:46 ` Kevin Hilman
2011-09-02 6:05 ` Jarkko Nikula
0 siblings, 1 reply; 9+ messages in thread
From: Kevin Hilman @ 2011-09-01 17:46 UTC (permalink / raw)
To: javier Martin; +Cc: linux-omap, Koen Kooi
javier Martin <javier.martin@vista-silicon.com> writes:
> Hi Kevin,
> thanks for your help.
>
>> CPU is staying in C0 probably because UARTs are not being idled, so SoC
>> cannot hit deeper idle states. Try the following at the command line to
>> to enable UART idle timeouts, so the SoC can attempt idle after the
>> timeout period
>>
>> # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
>> echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>> echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>> echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>>
>> After 5 seconds of inactivity on the UARTs, you should see the SoC
>> hitting deeper C-states.
>
> I've tried that but it still doesn't hit any C-state deeper than 0.
> I'll try the same test using your pm branch you pointed me out and
> post the results.
>
The CPUidle stuff works in mainline (after allowing UARTs to idle).
You only need my pm-wip/cpufreq branch for testing CPUfreq.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-01 17:46 ` Kevin Hilman
@ 2011-09-02 6:05 ` Jarkko Nikula
2011-09-02 7:23 ` javier Martin
0 siblings, 1 reply; 9+ messages in thread
From: Jarkko Nikula @ 2011-09-02 6:05 UTC (permalink / raw)
To: Kevin Hilman; +Cc: javier Martin, linux-omap, Koen Kooi
On 09/01/2011 08:46 PM, Kevin Hilman wrote:
> javier Martin<javier.martin@vista-silicon.com> writes:
>
>> Hi Kevin,
>> thanks for your help.
>>
>>> CPU is staying in C0 probably because UARTs are not being idled, so SoC
>>> cannot hit deeper idle states. Try the following at the command line to
>>> to enable UART idle timeouts, so the SoC can attempt idle after the
>>> timeout period
>>>
>>> # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
>>> echo 5> /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>>> echo 5> /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>>> echo 5> /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>>> echo 5> /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>>>
>>> After 5 seconds of inactivity on the UARTs, you should see the SoC
>>> hitting deeper C-states.
>> I've tried that but it still doesn't hit any C-state deeper than 0.
>> I'll try the same test using your pm branch you pointed me out and
>> post the results.
>>
> The CPUidle stuff works in mainline (after allowing UARTs to idle).
Other usual things to check that display is off (echo 1 >
/sys/class/graphics/fb0/blank) and no cable to musb/otg port.
Haven't tried myself with recent kernel but does EHCI and hub on XM let
to idle cpu at all? At least on one board having on-board hub I had to
disable or unload ehci module in order to hit the retention.
--
Jarkko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-02 6:05 ` Jarkko Nikula
@ 2011-09-02 7:23 ` javier Martin
2011-09-02 17:14 ` Kevin Hilman
0 siblings, 1 reply; 9+ messages in thread
From: javier Martin @ 2011-09-02 7:23 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: Kevin Hilman, linux-omap, Koen Kooi
On 2 September 2011 08:05, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
> Other usual things to check that display is off (echo 1 >
> /sys/class/graphics/fb0/blank) and no cable to musb/otg port.
>
> Haven't tried myself with recent kernel but does EHCI and hub on XM let to
> idle cpu at all? At least on one board having on-board hub I had to disable
> or unload ehci module in order to hit the retention.
>
I've checked that too and I've even disabled USB support in the kernel
just to be sure. But still nothing:
root@beagleboard:~# powertop -d -t 100
PowerTOP 1.12 (C) 2007, 2008 Intel Corporation
Collecting data for 100 seconds
Cn Avg residency
C0 (cpu running) ( 0.0%)
C0 58.5ms (100.0%)
C1 0.0ms ( 0.0%)
C2 0.0ms ( 0.0%)
C3 0.0ms ( 0.0%)
C4 0.0ms ( 0.0%)
C5 0.0ms ( 0.0%)
C6 0.0ms ( 0.0%)
Even when CPU has been idle 100% of the time it doesn't hit any state
deeper than C0.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-02 7:23 ` javier Martin
@ 2011-09-02 17:14 ` Kevin Hilman
2011-09-05 8:04 ` javier Martin
0 siblings, 1 reply; 9+ messages in thread
From: Kevin Hilman @ 2011-09-02 17:14 UTC (permalink / raw)
To: javier Martin; +Cc: Jarkko Nikula, linux-omap, Koen Kooi
javier Martin <javier.martin@vista-silicon.com> writes:
> On 2 September 2011 08:05, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
>> Other usual things to check that display is off (echo 1 >
>> /sys/class/graphics/fb0/blank) and no cable to musb/otg port.
>>
>> Haven't tried myself with recent kernel but does EHCI and hub on XM let to
>> idle cpu at all? At least on one board having on-board hub I had to disable
>> or unload ehci module in order to hit the retention.
>>
>
> I've checked that too and I've even disabled USB support in the kernel
> just to be sure. But still nothing:
>
> root@beagleboard:~# powertop -d -t 100
> PowerTOP 1.12 (C) 2007, 2008 Intel Corporation
>
> Collecting data for 100 seconds
>
>
> Cn Avg residency
> C0 (cpu running) ( 0.0%)
> C0 58.5ms (100.0%)
> C1 0.0ms ( 0.0%)
> C2 0.0ms ( 0.0%)
> C3 0.0ms ( 0.0%)
> C4 0.0ms ( 0.0%)
> C5 0.0ms ( 0.0%)
> C6 0.0ms ( 0.0%)
>
> Even when CPU has been idle 100% of the time it doesn't hit any state
> deeper than C0.
Did you allow the UARTs to idle:
# UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
I just tested this using today's linux-omap master branch (+ merged
v3.1-rc4 which includes a fix for a bootup problem.)
I booted my Beagle XM with a busybox rootfs on MMC and it worked fine
for me.
I don't have powertop on the rootfs, but I manually dumped the sysfs
files that powertop reads, so I can see the state times.
After allowing the UARTs to idle, I see:
# cd /sys/devices/system/cpu/cpu0
/sys/devices/system/cpu/cpu0/cpuidle # cat state?/time
43531831
8997
157215
0
3467925
0
0
Kevin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-02 17:14 ` Kevin Hilman
@ 2011-09-05 8:04 ` javier Martin
2011-09-06 21:04 ` Kevin Hilman
0 siblings, 1 reply; 9+ messages in thread
From: javier Martin @ 2011-09-05 8:04 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Jarkko Nikula, linux-omap, Koen Kooi
On 2 September 2011 19:14, Kevin Hilman <khilman@ti.com> wrote:
> javier Martin <javier.martin@vista-silicon.com> writes:
>
>> On 2 September 2011 08:05, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
>>> Other usual things to check that display is off (echo 1 >
>>> /sys/class/graphics/fb0/blank) and no cable to musb/otg port.
>>>
>>> Haven't tried myself with recent kernel but does EHCI and hub on XM let to
>>> idle cpu at all? At least on one board having on-board hub I had to disable
>>> or unload ehci module in order to hit the retention.
>>>
>>
>> I've checked that too and I've even disabled USB support in the kernel
>> just to be sure. But still nothing:
>>
>> root@beagleboard:~# powertop -d -t 100
>> PowerTOP 1.12 (C) 2007, 2008 Intel Corporation
>>
>> Collecting data for 100 seconds
>>
>>
>> Cn Avg residency
>> C0 (cpu running) ( 0.0%)
>> C0 58.5ms (100.0%)
>> C1 0.0ms ( 0.0%)
>> C2 0.0ms ( 0.0%)
>> C3 0.0ms ( 0.0%)
>> C4 0.0ms ( 0.0%)
>> C5 0.0ms ( 0.0%)
>> C6 0.0ms ( 0.0%)
>>
>> Even when CPU has been idle 100% of the time it doesn't hit any state
>> deeper than C0.
>
> Did you allow the UARTs to idle:
Yes I did:
root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
/sys/devices/platform/omap/omap_uart.0/sleep_timeout
root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
/sys/devices/platform/omap/omap_uart.1/sleep_timeout
root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
/sys/devices/platform/omap/omap_uart.2/sleep_timeout
root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
/sys/devices/platform/omap/omap_uart.3/sleep_timeout
[ 65.853820] omap_device: omap_uart.3: new worst case activate
latency 0: 30517
[ 65.944366] omap_device: omap_uart.2: new worst case deactivate
latency 0: 30517
> # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
> echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> I just tested this using today's linux-omap master branch (+ merged
> v3.1-rc4 which includes a fix for a bootup problem.)
>
> I booted my Beagle XM with a busybox rootfs on MMC and it worked fine
> for me.
>
> I don't have powertop on the rootfs, but I manually dumped the sysfs
> files that powertop reads, so I can see the state times.
>
> After allowing the UARTs to idle, I see:
>
> # cd /sys/devices/system/cpu/cpu0
> /sys/devices/system/cpu/cpu0/cpuidle # cat state?/time
> 43531831
> 8997
> 157215
> 0
> 3467925
> 0
> 0
OK, I've just tried with the same kernel as you did (linux-omap master
+ v3.1-rc4 merge) and I can't get any other state than 0:
root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# cat state?/time
162570397
0
0
0
0
0
0
Just one question. Do you access the shell through UART?
What I do is waiting for 20 seconds to allow the UART to suspend and
then see state reports.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: cpuidle status in mainline for Beagleboard xM
2011-09-05 8:04 ` javier Martin
@ 2011-09-06 21:04 ` Kevin Hilman
0 siblings, 0 replies; 9+ messages in thread
From: Kevin Hilman @ 2011-09-06 21:04 UTC (permalink / raw)
To: javier Martin; +Cc: Jarkko Nikula, linux-omap, Koen Kooi
javier Martin <javier.martin@vista-silicon.com> writes:
> On 2 September 2011 19:14, Kevin Hilman <khilman@ti.com> wrote:
>> javier Martin <javier.martin@vista-silicon.com> writes:
>>
>>> On 2 September 2011 08:05, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
>>>> Other usual things to check that display is off (echo 1 >
>>>> /sys/class/graphics/fb0/blank) and no cable to musb/otg port.
>>>>
>>>> Haven't tried myself with recent kernel but does EHCI and hub on XM let to
>>>> idle cpu at all? At least on one board having on-board hub I had to disable
>>>> or unload ehci module in order to hit the retention.
>>>>
>>>
>>> I've checked that too and I've even disabled USB support in the kernel
>>> just to be sure. But still nothing:
>>>
>>> root@beagleboard:~# powertop -d -t 100
>>> PowerTOP 1.12 (C) 2007, 2008 Intel Corporation
>>>
>>> Collecting data for 100 seconds
>>>
>>>
>>> Cn Avg residency
>>> C0 (cpu running) ( 0.0%)
>>> C0 58.5ms (100.0%)
>>> C1 0.0ms ( 0.0%)
>>> C2 0.0ms ( 0.0%)
>>> C3 0.0ms ( 0.0%)
>>> C4 0.0ms ( 0.0%)
>>> C5 0.0ms ( 0.0%)
>>> C6 0.0ms ( 0.0%)
>>>
>>> Even when CPU has been idle 100% of the time it doesn't hit any state
>>> deeper than C0.
>>
>> Did you allow the UARTs to idle:
>
> Yes I did:
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.0/sleep_timeout
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.1/sleep_timeout
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.2/sleep_timeout
> root@beagleboard:/sys/devices/system/cpu/cpu0/cpuidle# echo 5 >
> /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>
> [ 65.853820] omap_device: omap_uart.3: new worst case activate
> latency 0: 30517
> [ 65.944366] omap_device: omap_uart.2: new worst case deactivate
> latency 0: 30517
>
>
>> # UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
>> echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
>> echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
>> echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
>> echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
>>
>> I just tested this using today's linux-omap master branch (+ merged
>> v3.1-rc4 which includes a fix for a bootup problem.)
>>
>> I booted my Beagle XM with a busybox rootfs on MMC and it worked fine
>> for me.
>>
>> I don't have powertop on the rootfs, but I manually dumped the sysfs
>> files that powertop reads, so I can see the state times.
>>
>> After allowing the UARTs to idle, I see:
>>
>> # cd /sys/devices/system/cpu/cpu0
>> /sys/devices/system/cpu/cpu0/cpuidle # cat state?/time
>> 43531831
>> 8997
>> 157215
>> 0
>> 3467925
>> 0
>> 0
>
> OK, I've just tried with the same kernel as you did (linux-omap master
> + v3.1-rc4 merge) and I can't get any other state than 0:
> Just one question. Do you access the shell through UART?
Yes.
> What I do is waiting for 20 seconds to allow the UART to suspend and
> then see state reports.
Then I suspect your userspace is keeping the system active.
Can you try to just boot a minimal userspace (e.g. append init=/bin/sh
to your kernel command line, or use a basic busybox rootfs.)
Keivn
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-09-06 21:04 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-01 14:14 cpuidle status in mainline for Beagleboard xM javier Martin
2011-09-01 15:10 ` Kevin Hilman
2011-09-01 15:33 ` javier Martin
2011-09-01 17:46 ` Kevin Hilman
2011-09-02 6:05 ` Jarkko Nikula
2011-09-02 7:23 ` javier Martin
2011-09-02 17:14 ` Kevin Hilman
2011-09-05 8:04 ` javier Martin
2011-09-06 21:04 ` Kevin Hilman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.