박사라이팅

추천시스템이란?

박사님공부하셔야죠 — Mon, 28 Apr 2025 20:51:16 +0900

How can we help users get access to relevant items?

(어떻게 하면 사람들이 관련된 항목에 쉽게 노출될 수 있을까?)

추천시스템이란?

사용자 개인에게 맞춤형 아이템이나 정보를 자동으로 제안하는 기술

이 기술은 넷플릭스, 인스타그램 등 다양한 어플리케이션에 적용되고 있음. 예를 들어, 넷플릭스는 소비자가 흥미로워할 만한 영화나 드라마를 추천 목록에 노출시켜 소비자가 관심 있는 작품을 선택하도록 유도함. 이는 소비자에게는 새로운 콘텐츠를 발견할 수 있는 기회를 제공하고, 넷플릭스에는 고객 확보라는 이점을 가져옴.

그러나 개인에게 최적화된 아이템을 추천하는 것은 쉬운 과제가 아님. 소비자가 아직 보지 않은 아이템, 좋아할 가능성이 높은 아이템, 주변 친구들이 많이 본 아이템 등 다양한 요소를 함께 고려해야 하는 복잡성이 존재함.

특히 추천을 위해서는 소비자의 선호를 어느 정도 파악해야 하지만, 현실에서는 데이터가 매우 희소한 경우가 많음. 예를 들어 넷플릭스 초기 가입자는 드라마나 영화를 클릭한 기록이 없기 때문에, 이들에게 적절한 추천을 제공하는 데 어려움이 따름. 또한 개인정보 보호 이슈로 인해 기업이 소비자의 선호 데이터를 자유롭게 수집하고 활용하는 데 제한이 존재함.

결론적으로 추천 시스템은 Sparse한(희소한) 데이터를 바탕으로 사용자의 선호를 예측하는 기술이며, 예측 정확도가 높을수록 기업의 영업 성과가 향상되는 효과를 기대할 수 있음.

추천시스템은 보통 top-k recommendation과 rating임. 모델도 정말 많아서 Neighborhood-based Collaborative Filtering부터 차근차근 리뷰할 예정임.

CXL Switch

박사님공부하셔야죠 — Mon, 6 Jan 2025 21:24:37 +0900

CXL Switch란??

CXL protocol을 기반으로 여러 CXL device와 host를 연결하는 HW device임. PCIe switch와 유사하지만, CXL의 cache coherency와 memory expander을 지원하는 기능이 추가됨.

Host와 Device간의 연결을 Virtual port로 연결함. 여러 Host는 각자의 Address Space를 가지고 있으며, CXL device는 Single Logical Device (SLD), Multi Logical Device (MLD)로 되어 있음. PCIe Device도 사용 가능. 대신에 CXL protocol이 아닌 PCIe protocol을 사용.

SLD는 하나의 physical device가 단일의 logical device로 host가 인식되는 경우로 하나의 address space로 인식. MLD는 하나의 physical device가 여러 logical device로 host가 여러 space로 인식해서 독립적인 device로 인식함.

MLD는 용량이 큰 하나의 Device Attached Memory (DAM)임. Logical Device (LD)는 각자의 partition이 있음. CXL 2.0에서는 MLD가 16 partition으로 쪼개질 수 있음. DAM이 16TB이면, 하나의 LD는 1TB임. MLD Device는 FM-LD (Fabric Managed LD)가 있어 16bit의 LD-ID를 가지고 사용가능한 LD를 정의함. Host는 FM-LD가 visible하지 않음. 대신 CXL Switch에 있는 Fabric Manager Programs Binding이 visible하여, host에 맞는 LD를 binding해줌. 당연하듯, 각 LD는 각자의 partition에만 accessible함.

이런 Switch가 있어서 여러 Host가 여러 Device를 access 할 수 있으며, cache coherency가 보장되기 때문에 cacheable함.

CXL Type-3 Device Data Flow

박사님공부하셔야죠 — Mon, 6 Jan 2025 21:02:28 +0900

CXL type-3 device는 memory expander처럼 cxl.io와 cxl.mem protocol만 가능한 cxl device임.

Host to Device Config/MMIO Access

다른 점은 Direct Memory Access (DMA)가 device에 없음. 왜??? 당연히, Memory Expander와 같은 type-3 device에서는 device to host access가 없기 때문임.

또 Device Attached Memory (DAM)은 Host에서 cacheable한 memory임. PCIe와 다름. 왜??? PCIe Deivce는 cache coherency를 보장하지 않음. CXL은 보장하기 때문에 가능함.

먼저 Base Address Register가 있는 Device의 Config/MMIO로 host가 접근함. 이 때, CXL.io protocol을 사용해서 접근함.

Host to Device Attached Memory (DAM) Access

Host의 IO MMU와 Bridge는 사용하지 않음. 왜??? Device에서 DMA가 없어 Device to Host access가 일어나지 않기 때문에, 굳이 Address Translation할 필요가 없음.

위 과정으로 Host to DAM access를 진행함. 이 때 CXL.mem protocol을 함. 조금 전 설명했듯이, DAM은 cacheable하기 때문에 Host cache에 저장할 수 있음.

DMA가 있는 type-3 CXL Deivce (Hybird)

CXL document에 없는 Hybrid type-3 Device가 아래와 같음. DMA가 있어서 Device가 Host로 access가능.

PCIe와 비슷하면서도 사뭇다름. DAM이 cacheable한다는 것이 크게 다른 점.

PCIe Device 예시

박사님공부하셔야죠 — Mon, 6 Jan 2025 20:41:58 +0900

PCIe Device가 Host Processor와 communication하는 절차를 설명하고자 함. Private Device Memory가 없을 때, 상황을 설명.

Host to Device Config/MMIO Access

Host Processor가 Device의 Config/MMIO space에 접근함. 이 때, PCIe Transaction 사용. BAR (Base Address Register)을 사용하여, MMIO space에 접근.

정리하자면, 이 PCIe Transaction을 통한 Host to Device Access로, Device의 Config Space와 MMIO space에 communication함.

Device to Host MMU Access

Device가 Host에 Access하기 위해서는 Address Translation이 필요함. 이 때, Device가 Address Translation Request를 보내는데, Untranslated Address를 Host에게 보냄. Host에서는 Translated된 Packet을 다시 Device에게 줌. 이를 통해 Device는 Host에게서 security admission을 받음.

Device to Host with DMA

이제 DMA을 통해 Host에 있는 data을 Device로 받아야함. Host Memory에 Read와 Write하기 위해 위와 같은 과정을 거침. PCIe Device는 Cache가 없음. PCIe protocol에서는 Cache Coherency가 없기 때문임. Host Memory는 Cachable하기 때문에, Host Cache가 존재. 먼저 DMA Engine에서 MRd, MWr을 HCOH (Coherency Bridge)에 보내고, HCOH는 해당하는 cache line이 Modified상태인지 확인. Modified일 경우, Host Memory보다 Host Cache에 있는 data가 최신이므로, Host Cache에서 data을 device가 받을 수 있음. 또한, HCOH에서 Host Cache의 Snoop할 수 있어, Cache Coherency를 보장할 수 있음. Packet에서 NS bit가 있는데, NS bit가 set되면, HCOH에서 snoop없이 무조건 directly하게 Host Memory으로부터 Device가 Data을 받음. 이를 통해 snoop에 의한 latency가 없어짐.

이제 Private Device Memory (PDM)이 있을 때 과정을 설명하고자 함. 근데 위와 거의 비슷.

Host to Device Config/MMIO Access

Host가 Device의 Config와 MMIO로 접근할 때 아래와 같음.

Private Device Memory (PDM)은 Host Memory의 extension이 아님. 그렇다고 access가 불가능한 것은 절대 아님. 이 Host to Device Config/MMIO Access는 PDM 없을 때와 거의 같지만, PDM에 BAR가 있어 PDM에 access하는 과정이 있음. 그래야 PDM에 read나 write할 수 있음. 똑같이 MMIO space는 Host Cache에 not cacheable함.

Device to Host MMU Access

이것도 PDM없을 때와 똑같음. Address Translation 및 Grant를 받을 수 있음.

Device & Host Access with DMA

Device to PDM이라는 과정이 추가됨. 이 과정은 PCIe Link을 타지 않음. 자기 자신의 PDM을 access하기 때문임.

CXL protocol & Device type

박사님공부하셔야죠 — Fri, 3 Jan 2025 14:19:47 +0900

CXL protocol

CXL protocol에는 3가지가 있음.

CXL.io, CXL.cache, CXL.mem으로 각자 역할이 다름.

CXL.io은 PCIe기반으로 device discovery, status reporting, virtual to physical address translation, direct memory access (DMA)에 사용됨.

CXL.cache는 device가 system memory를 caching할 때 사용됨.

CXL.mem은 CPU와 다른 CXL device가 device memory을 cachable memory (HDM)처럼 접근할 때 사용됨. 하나의 host memory처럼 보임.

CXL type

Type-1은 smart NICs와 같은 가속기를 말함. PCIe형태의 DMA transfer로 coherency 관리. CXL.io와 CXL.cache 사용.

Type-2은 GP-GPUs와 FPGAs같이 local memory가 있어, cacheable system memory에 mapping될 수 있는 가속기를 말함. system memory을 caching할 수 있음. 따라서, CXL.io, CXL.cache, CXL.mem 사용.

Type-3은 CXL.io와 CXL.mem을 사용함. cost, power, pin-efficient한 DDR channel추가 등을 할 수 있음.

CXL 이후와 이전

박사님공부하셔야죠 — Fri, 3 Jan 2025 13:48:39 +0900

CXL (Compute Express Link) 이전에는 PCIe (Peripheral Component Interconnect Express)를 사용하여, GPU, GP-GPUs, FPGA 등의 다양한 가속기와 storage를 연결하여 사용하였음.
DDR (Double Data Rate)로 CPU와 연결해서 병렬 인터페이스를 사용했었음.

하지만, 광범위한 종류 및 개수의 device를 관리하기에는 한계가 있음. 아래가 몇 가지 한계점임.

Challenge 1 : Coherent Access to System and Device Memory

이전에는 DDR를 통해, System memory가 사용되고, CPU cache 계층적 구조로 캐싱이 가능하였음. 반대로, PCIe device에서 system memory로 접근할 대, non-coherent reads/wirtes가 발생함. PCIe device가 system memory를 캐시할 수 없어서, locality를 활용할 수 없고, operation을 연속으로 처리 불가능함. 매번 device에서 system memory로 read/write할 때 host의 RC (root complex)를 통해서 PCIe는 CPU cache와 coherency를 지켜야 함. 비슷하게, PCIe device에 부착된 memory는 host로 부터 non-coherently 접근됨. 이 때문에 device memory는 캐싱 가능한 system address space에 mapping을 할 수 없음.

이러한 non-coherent 접근은 I/O operation에는 잘 작동함. 문제는 가속기임. 전체 data를 system memory로 부터 가속기에 이동시켜야 하고 동작해야함. 이 때, main memory에 다시 data가 이동하기 전에 마쳐야 하고 CPU와 가속기 사이에 동시 접근을 맞기 위해 software가 필요하게 됨. 이 같은 data 이동은 AI, ML (Machine Learning), NICs (Network Interface Cards)에 치명적인데, device가 device-local cache를 사용하여 CPU와 동시에 동일한 data에 접근하려 하고 data 전체를 이동시키지 않기 때문임.

Challenge 2 : Memory Scalability

막대한 계산량을 포괄하기 위해 Memory 용량과 대역폭을 늘리려 요즘 사력을 다하고 있음. 근데, DDR memory는 이러한 요구에 적합하지 못함. CPU당 대역폭이 낮기 때문임. 병렬 DDR interface의 pin-inefficiency (데이터를 전송하기 위해 많은 핀이 필요하지만, 효율적으로 사용되지 않아 HW complexity 및 power 소모 증가) 때문임. DDR channel을 더해서 scaling up을 하더라도 문제가 있음. PCIe는 DDR보다 적은 pin으로도 같은 대역폭을 낼 수 있어서 그나마 나음. PCIe는 근데, coherency를 지원하지 않고 device에 부착된 memory를 coherent memory space에 mapping할 수 없음. 그러므로, PCIe는 DDR을 대채할 수 없음.

Challenge 3 : Memory and Compute Inefficiency Due to Stranding

오늘날 datacenter는 활용되지 못하는 resource 때문에, 비효율적임. memory와 같은 resource는 idle capacity가 남아 있을 때 활용되지 못하고 다른 compute와 같은 다른 resource는 fully used됨. compute, memory와 I/O device가 하나의 server에서 동작하는 것이 주요 원인임. 결과적으로 각 server는 memory와 가속기를 많이 공급받아서, 최적의 capacity demands를 다룰 수 있도록 해야함. 하지만, server은 memory가 사용되지 않은 채로 종종 남을 것임. 이런 활용되지 않은 memory는 power, cost, sustainability 등 다양한 부분에서 low resource utilization을 유발함.

Challenge 4 : Fine-grained Data Sharing In Distributed Systems

분산 시스템에서 fine-grained synchronization을 주로 의존함. 더 상세한 단위로 data를 공유하기 때문에, datacenter에서 communication delay가 큼.

The role of CXL

위 4가지 단점을 해결할 수 있는 CXL.

CXL 1.0은 coherency와 memory semantic 중 하나를 골라서 할 수 있음. CXL은 custom link와 transaction layer를 사용하여 remote socket memory access보다 더 적은 latency를 가짐. Challenge 1과 2를 해결 가능.

CXL 2.0은 Challenge 3을 multiple host에서 resource pooling을 하여 해결. CXL switch를 활용하여 여러개의 device를 pooling함. Pooling 덕분에 underutilization이 감소.

CXL 3.0은 Challenge 3을 해결하는데, CXL switch가 더 많이 들어감. pooling 및 resource간의 sharing이 가능하여, Challenge 4를 해결.

CXL Port Layered Architecture

박사님공부하셔야죠 — Tue, 24 Dec 2024 16:30:42 +0900

CXL에서는 여러 Layer가 Data Packet을 송신 및 수신하여 분해, 오류 검증을 단계별로 진행함.

CXL Layer Architecture

CXL Transaction Layer에서는 managing 담당.
CXL Link Layer에서는 Transaction를 받고 flit으로 바꿈.
CXL ARB/MUX Layer에서는 .io, .cache, .mem 프로토콜 통합.
Flex Bus Physical Layer에서는 flit을 송신 및 수신.

Transaction Layer

CXL.io (IO side) 지원하여 ATS extension, Deferred Writes, Vendor Defined Message등 CXL 성능을 높임.
CXL.mem, CXL.cache (Cache & Mem side) protocol 지원함.

처음부터 끝까지, CXL.mem과 CXL.cache transaction을 tracking함.
tracking할 때, tag (16 bits)와 CQID & UQID (12 bits)을 사용.

Link Layer

IO filt (IO side), cache 및 memory flit (Cache & Mem side)을 만듦.
TLP와 DLLP를 Flit으로 만듦.
Flow Control 및 ACK, NACK Error Detection, Correction 가능.

ARB/MUX Layer

어느 flit을 보낼지 결정.
- CXL.io (IO side)와 CXL.cache 및 CXL.mem (Cache & Mem side)에서 만든 packet을 동적으로 선택함.
- 이 때, 두 protocol사이에 누구를 고를 것인지는 Weighted Round Robin Arbitration 사용.
32 GT/s로 PCIe 5.0 PHY에 Packet이 송신됨.
virtual Link State Machines (vLSM)로 송수신 관리.
- CXL.io LL와 CXL.cache/mem LL두 Link Layer의 protocol로 부터의 request를 다룸.
- ARB/MUX Layer Link Management Packets (ALMP) Flits는 두 link의 vLSM 사이의 communication을 위하여 쓰임.

Logical Physical Layer

Byte Striping, 8b/10b, 128b/130b, Scrambling 담당.
이를 통해 아래와 같은 것을 할 수 있음.

CXL.io Flits, CXL.cache/mem Flits, ALMP Flits, NULL Flits 앞에 Protocol ID를 추가 가능.
송신할 다른 Flit이 없으면 NULL flit 삽입.
Latency Optimized Mode로 설정 가능.
Link Training와 LTSSM 수정을 할 수 있음.

Flits (CXL Native Packets)

Flit은 68B로 구성되어 있음. (Protocol ID + Flit Payload + CRC or 0s)

Flit 구성

unique한 Protocol ID로 4개의 Flit type를 나타냄

CXL.io Flits (TLPs 와 DLLPs가 Flit payload안에서 전송됨)
CXL.cache/CXL.mem Flits
- 다양한 format으로된 Protocol Flits
- All-Data Flits
- Control Flits
ALMP (ARM/MUX Layer Link Management Packets) Flits
NULL Flits

CXL 이란 무엇일까

박사님공부하셔야죠 — Tue, 24 Dec 2024 15:07:31 +0900

CXL (Compute Express Link)란?

고성능 컴퓨팅 시스템에서 processor와 다양한 device(가속기, memory expansion, smart I/O device) 간의 표준화된 high-speed interconnect
주로 PCIe 기반 (PCIe 5.0이며 32.0 GT/s, 64.0 GT/s의 data 전송 속도를 가지는 x16, x8, x4 link width를 제공)

CXL에서 사용하는 중요한 3가지 protocol

CXL의 transaction layer에서는 3가지 protocol 제공
- CXL.io
  - PCIe 5.0기반으로 device를 발견
  - Configuration 진행
  - 초기화 진행
- CXL.cache
  - CXL device (ex. memory expander) 가 host processor의 memory에 access할 수 있도록 만듦
  - cache coherence를 관리
- CXL.mem
  - host가 device에 부착된 memory (memory expander)에 접근할 수 있도록 함
  - 이때 load/store command 사용

CXL Device의 3가지 type

Type-1 device

Smart NIC처럼 DDR memory와의 통신을 하기 위한 CXL.io, CXL.cache 사용

Type-2 device

GPU, ASIC, FPGA가 해당
CXL.io, CXL.cache, CXL.mem 사용하여 processor와 memory를 공유하고 같은 cache domain에서 다양한 workload의 성능을 개선

Type-3 device

CXL.io와 CXL.mem을 사용하여 memory expansion과 pooling을 함
DRAM 용량 확보 가능, memory 대역폭 향상, DRAM slot 사용없이 비휘발성 메모리 추가 가능
high-speed, low-latency storage로 DRAM을 보완하는 기능을 가짐
거의 많이 사용됨

CXL을 왜 사용할까

CXL 등장 전

PCIe로 데이터 전송
Cache Coherence 문제 발생
CPU 메모리 접근이 어려워 별도의 DMA control이 필요하였음
데이터 복제가 비번해서 latency 증가 및 resource 낭비 발생
device간 메모리 공유가 비효율적임

CXL 등장 후

PCIe기반이지만, protocol을 통해 cache coherency와 memory share가능
latency 감소, 효율적인 interconnect 생성 가능

결국은 cache coherence 문제를 CXL이 잘 다뤄서 성능 부분에서 극대화 되는 듯한 느낌

PCIe의 TLP (Transaction Layer Packet)은 4KB payload size를 지원
CXL은 더 작은 64B Flit payload size를 지원하기 때문에, 데이터 전송 및 수신 했을 때 처리 하는 과정이 짧음
이에 CXL이 PCIe와 비슷한 대역폭을 가지면서 latency는 작음

CXl의 Flex Bus Port로 CXL device가 아닌 PCIe device도 지원함

CXL VERSION (1.0, 2.0, 3.0)

CXL 1.1과 2.0 비교. CXL switch로 memory pooling 가능

CXL 1.0 (2019년 발표)

CXL protocol 갖춤
우리가 잘 아는 CXL

CXL 2.0 (2020년 발표)

1.0에서 기능 추가
메모리 풀링 : 여러 CPU가 동일한 메모리 리소스를 공유할 수 있도록 지원
메모리 보안 : 데이터 암호화 및 보안 기능 강화
Hot-plug 지원 : 동적 장치 연결/해제 기능
CXL switch 지원 : device가 여러 개 일 때 필요함

CXL 3.0으로 Fabric 형성. 많은 host processor가 device를 효율적으로 interconnect함.

CXL 3.0 (2022년 발표)

멀티 헤드 디바이스 : 여러 host processor가 하나의 device를 동시에 활용 가능
Fabric 지원 : 다중 노드 간의 네트워크 구조 (Fabric)을 통해 확장성 극대화
Bandwidth improved : PCIe 6.0과 호환성을 통해 더 빠른 데이터 전송 가능
리소스 공유 개선 : 더 정교한 메모리 공유 및 관리 기능

c++에서 값 초기화

박사님공부하셔야죠 — Fri, 4 Oct 2024 00:36:41 +0900

c++코딩하는 중에 착오가 있어서 초기화가 제대로 되지 않았다.

    int max_index_list[TLB_SET] = {0};
    int min_index_list[TLB_SET] = {0};

c++에서 배열을 선언함과 동시에 모든 값을 위와 같이 0으로 초기화가 가능하다.

하지만 코드를 선언하고 사용한 뒤에 다시 초기화 할 때면 아래와 같은 방법으로는 사용할 수 없다.

max_index_list[TLB_SET] = {0};
min_index_list[TLB_SET] = {0};

이러면 초기화가 안된다...... 이래서 이상한 데이터로 분석하고 있었음....

이미 선언한 배열을 초기화 하려면 std::fill이나 memset을 사용하면 된다.

std::fill(max_index_list, max_index_list+TLB_SET, 0);
std::fill(min_index_list, min_index_list+TLB_SET, 0);

이러면 0으로 전체 값이 초기화 된다.

std:: 를 써줘야지 vscode에서 다음과 같은 에러가 나오지 않는다.

위의 에러는 동일한 이름의 함수가 있어 충돌이 발생할 수 있다는 에러다. 에러라 해도 처음에는 돌아가지만, std::를 명시하지 않으면 std::로 돌렸는지 다른 fill 함수로 돌렸는지 알 수 없으니 웬만해서는 쓰도록 하자.

VSCode 갑자기 안 될 때 (SSH 사용 시) : Failed to parse remote port from server output

박사님공부하셔야죠 — Sun, 22 Sep 2024 17:32:11 +0900

ssh 원격으로 서버 컴퓨터에 잘만 접속하다가, 갑자기 위 (Failed to parse remote port from server output) 에러가 뜨면서 연결이 안되는 문제가 발생하였다.

도대체 뭐지????

신기하게도 vscode로 ssh 연결할 때에만 안되고, MobaXterm으로 할 때에는 가능했다.

예상되는 원인은 vscode가 업데이트 되면서 서버 컴퓨터에 ~/.vscode-server 내용과 버전이 불일치 되는 것이라 판단된다.

vscode로 ssh 호스트 연결할 때 어차피 ~/.vscode-server는 자동으로 만들어 주기 때문에 해당 폴더를 삭제하고 재접속하였다.

rm -rf ~/.vscode-server

그러더니 재접속 성공!!

vscode 잘만 되다가 안된다 싶으면 위 명령어를 서버 컴퓨터에 입력하자.