could not find kernel image /casper/vmlinuz

when using pendrivelinux, make sure to format the usb drive so it has the right file system (fat32), otherwise syslinux will throw an error.

if the usb drive boots but throws an error like in the title above, check if there’s a file called vmlinuz in the casper directory. if there’s only a vmlinuz.efi file, copy it and rename it to vmlinuz. booting the kernel should work after this.

파일 명을 변경시켜서 부팅 시켜야 한다니......... 이거 해결한다고 오늘 시간 날림.......

git install

http://git-scm.com/book/en/Getting-Started-Installing-Git

git 관련 tool

http://seoz.egloos.com/3910833

git 기본 사용법

http://blog.hibrainapps.net/18

Wide IO 에서 512bit 즉 32byte단위 접근이라는 것은

BANK  단위의 접근이 아니라 RANK 단위의 접근이다.

DDR 시리즈에서 이어서 이야기를 써본다면

DDR은 동시에 BANK 에서 동시에 2배의 데이터를 꺼내어와 버스에서 속도를 가속 시켜 꺼내오는 방식이고

반면에, WIDE IO는... 이그림이 젤 좋겠다.

일단 나중에 설명해야지......

설명은 논문 : Variation-Tolerant Non-Uniform 3D Cache Management in Die Stacked Multicore Processor 참조

여기서 말하고 싶은거는 Each Bank 당 128bit를 꺼내오고 그 데이터 들은 왼쪽 위에 있는 4buffer에 저장되고 1개의 rank에 속해있는 4개의 bank에서 꺼내온 각각의 data들은 가져와서 512bit 즉 64byte를 만들어서 쓴다.

웃긴건 여기에 보면 Private L1이나 L2 둘다 64B의 line size를 가진다는 것이다.

참고로 왼쪽 위에 있는 그림은 1개의 rank의 peri 이고 저기에 있는 한개의 tag bank 와 4buffer 는 위로 stack되어있는 4개의 sub-bank 즉 1개의 bank를 지원해준다.

PID는 Process IDentifier로 프로세스 식별자라 하며 유닉스 커널과 같은 운영체계에서 각 프로세스나 서비스를 식별하기 위해 할당하는 고유한 번호이다. PID는 "fork"라는 시스템 호출에 의해 반환되며, 주어진 프로세스에 어떤 행동을 이행하기 위해 wait()나 kill()등이 전달될 수있다.

리눅스의 사용자가 하나의 명령어를 사용하기 위해 쉘 프롬프트에서 사용하고자 하는 어떤 명령을 입력하고 Enter를 치면 쉘은 그 이름이 먼저 쉘에서 제공되는 내부 명령인지 확인하고, 내부 명령으로 확인이 된다면 그것을 자체적으로 실행한다. 하지만 내부 명령이 아니라면 먼저 PATH환경 변수에 지정된 디렉토리를 검색해서 그 파일이 있는지 확인을 한 뒤 만약 그것이 있다면 그 파일을 실행하도록 커널에게 지시한다.

그러면 커널은 그 파일의 접근 권한과 사용자를 비교해서 실행 권한이 있는지 없는지 확인한 후 없다면 사용할 수 없음을 쉘에 보낸다. 그런데 비교해서 확인한 후 실행할 수 있다면 먼저 그 실행 파일의 내용을 메모리에 불러들이는 동시에 고유의 번호를 붙이는데, 이것을 앞서 언급한 프로세스 식별 번호(PID 번호 - Process IDentity number) 라고 한다.

이제 실행되고 있는 하나의 파일은 프로세스라고 한다는 것을 알고 있다. 이 번호는 각 프로세스들의 시작 순서에 따라 차례로 붙여진다. 이번호는 커널 측면에서 본다면 프로세스 관리에, 즉 다중 작업에 관계가 있다. 다시 말하자면 프로세스 식별 번호(PID 번호)는 사용자 측면에서 본다면 프로세스 중지 명령에서 사용된다.

출처 : 

http://blog.naver.com/PostView.nhn?blogId=bestheroz&logNo=67071284&parentCategoryNo=&categoryNo=13&viewDate=&isShowPopularPosts=false&from=postView

- 프로세스의 개념 및 종류

프로세스란 실행중인 프로그램을 의미한다고 할 수 있지만 이에 대해서는 여러 가지 다른 사항들에 대한 이해가 필요하며 다른 몇가지 용어들과의 차이도 함께 비교할 필요가 있다.

우선 작업(job)이라는 용어(이 용어는 이미 예전에 사라진 용어라 할 수도 있겠으나 프로세스에 대한 명확한 이해를 돕기 위하여 언급한다)에

대해 살펴보자. 일반적으로 사용자가 컴퓨터에서 실행시키기 위하여 작성한 프로그램과 이 프로그램의 실행에 필요한 입력 데이터를 묶어서 작업이라 한다. 결국 작업이란 프로그램과 이에 필요한 데이터를 의미하는 것으로 이는 컴퓨터에 실행 의뢰되기 전에 상태 또는 실행 의뢰되는 과정에서 사용하는 용어라 할 수 있다. 이러한 작업이 컴퓨터 시스템에 실행 의외되어 운영체제, 즉커널에서 이 사실이 전달되면 이 작업은 커널에 등록되며 이와 같이 커널에 등록된 작업을 이제부터 프로세스라 부른다. 다시 말하면, 프로세스란 커널에 등록되어 커널의 관리하에 들어간 작업을 말하는 것이다.

- 프로세스의 정의

커널에 등록되고 커널의 관리하에 있는 작업을 의미하며, 이를 일반적으로 실행중인 프로그램 또는 실행중인 작업이라 정의하고 있는 것이다. 그러나 프로세스의 정확한 정의 내지는 특성을 이해하기 위해서는 보다 세부적인 이해가 필요하다.

컴퓨터 시스템에 입력된, 즉 커널에 등록된 프로세스는 자신이 실행해야 할 프로그램을 가지고 있다. 이 프로그램을 실행시키기 위하여 프로세스는 커널에게 각종 자원(Resource)들을 요청하게 된다. 여기서 자원이란 기억 장치, 프로세서, 디스크 등의 각종 하드웨어 장치나 메시지, 파일 등의 소프트웨어 요소들을 의미한다. 다시 말하면, 프로세스는 자신이 실행해야 할 프로그램이나 이와 관련된 데이터를 기억 장치에 적재시키기 위하여 기억 장치를 요구할 것이며, 이를 실행시키기 위하여 프로세서도 요구 할 것이다. 또한 프로그램이 실행되는 동안 필요한 디스크 파일들에 접근하기 위하여 각종 파일들을 요구할 수도 있다. 이와 같은 관점에서 프로세스를 정희할 때 좁게는 프로세서를 할당받을수 있는 개체(Entity)로 , 넓게는 컴퓨터 시스템내의 각종 자원들을 요구하고 할당 받을 수 있는 개체로 정의하기도 한다.

커널은 프로세스를 관리하기 위하여 커널 공간(Kernel Space)내에 각 프로세스들에 대한 정보를 저장하고 사용한다. 이와 같이 커널에

등록된 각 프로세스들에 대한 정보를 저장하고 있는 영역을 프로세스 관리 블록(PCB : Process Control Block)이라 하는데, 프로세스를 이와 같이 PCB를 할당받는 개체로 정의하기도 한다.

지금까지 언급한 설명들을 종합하면 프로세스는

     실행중인 프로그램(작업)

     커널에 등록되고 커널의 관리하에 있는 작업

     각종 자원들을 요청하고 할당받을 수 있는 작업

     프로세스 관리 블록을 할당받는 개체

프로세스 관련 용어

다음 용어들간의 개념상 차이점을 명확히 구분해 보도록 하자.

◎ 프로그램(Program) : 특정 기능을 수행하기 위한 명령어의 조합

◎ 작업(Job) : 프로그램과 프로그램 실행에 필요한 입력 데이터

◎ 프로세스(Process) : 실행중인 프로그램의 인스턴스

◎ 프로세서(Processor) : 연산을 수행하고 처리하기 위한 자원, 보통 CPU를 말함

◎ 프로시저(Procedure) : 프로그램의 일부로 공통적으로 사용되는 특정 루틴

◎ 스레드(Thread) : 프로세스의 일부 특정 데이터만 가지고 있는 가벼운 프로세스

- 프로세스 자원의 개념

컴퓨터 시스템내에서 프로세스는 스스로 움직이는(프로그램이 실행되는 것을 이와 같이 표현한다.) 능동적인 개체인 데 비하여, 자원이란 커널에 의해 다른 주체에게 할당되고 이의 사용이 끝날 경우 다시 반납되는 파동적인 개체에 해당한다.

하드웨어자원은 기억 장치나 프로세서, 하드 디스크, 자기 테이프, 단말기, 모니터, 키보드 등의 각종 하드웨어 장치들을 의미하며, 소프트웨어 자원은 메시지, 시그널, 파일, 각종 공유 소프트웨어 등을 의미한다고 할 수 있다.

프로세스는 실행중에 각종 자원들을 요구하기도 하고 이를 할당받기도 하며, 사용이 끝났을 때에는 반납하기도 하면서 진행한다. 이에 따라 컴퓨터 시스템의 상태를 각종 프로세스들과 각종 자원들의 상호 작용(Interaction)으로 모델링하기도 한다.

- 프로세스 관리 블록

컴퓨터 시스템내의 프로세스들은 모두 커널 공간에 자신의 PCB를 하나씩 갖게 되며 이의 관리는 커널이 하게 된다. 다르게 설명하면 커널은 자신에게 등록된 프로세스들을 관리하기 위하여 프로세스마다 하나씩 PCB를 할당해 주고, 이 영역에 해당 프로세스에 대한 각종 정보들을 저장하여 프로세스를 관리할 때 사용한다.

PCB에 저장되는 프로세스 관련 정보들은 운영체제마다 조금씩 다를 수 있지만 일반적으로는 다음과 같은 정보들을 PCB에 유지하게 된다.

◎ 프로세스 고유 번호(PIN ; Process Identification Number)

◎ 프로세스의 우선 순위(Priority)

◎ 프로세스의 현재 상태(Current State)

◎ 프로세스가 할당받은 자원들의 리스트 또는 이들에 대한 포인터

◎ 문맥 저장 영역(Context Save Area)

여기서 프로세스의 고유 번호는 커널이 시스템내의 프로세스들을 관리하는데 있어서의 편리성을 위하여 프로세스마다 다르게 부여되는 번호이며 이는 프로세스가 생성될 때에 부여된다.

프로세스의 우선 순위는 프로세스 스케줄링에서 사용하기 위한 정보이며, 특히 운영체제가 우선 순위 기반 스케줄링(Priority-based Scheduling)을 하는 경우에 필요한 정보이다. 커널은 여러 프로세스들 중 프로세서를 할당할 프로세스를 선정하기 위해 이 우선 순위를 참조할 수 있다.

출처 

http://blog.naver.com/PostView.nhn?blogId=bestheroz&logNo=67017920&redirect=Dlog&widgetTypeCall=true

A JIT compiler runs after the program has started and compiles the code (usually bytecode or some kind of VM instructions) on the fly (or just-in-time, as it's called) into a form that's usually faster, typically the host CPU's native instruction set. A JIT has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently.

This is in contrast to a traditional compiler that compiles all the code to machine language before the program is first run.

To paraphrase, conventional compilers build the whole program as an EXE file BEFORE the first time you run it. For newer style programs, an assembly is generated with pseudocode (p-code). Only AFTER you execute the program on the OS (e.g., by double-clicking on its icon) will the (JIT) compiler kick in and generate machine code (m-code) that the Intel-based processor or whatever will understand.

CPU Bound means the rate at which process progresses is limited by the speed of the CPU. A task that performs calculations on a small set of numbers, for example multiplying small matrices, is likely to be CPU bound.

I/O Bound means the rate at which a process progresses is limited by the speed of the I/O subsystem. A task that processes data from disk, for example, counting the number of lines in a file is likely to be I/O bound.

Memory bound means the rate at which a process progresses is limited by the amount memory available and the speed of that memory access. A task that processes large amounts of in memory data, for example multiplying large matrices, is likely to be Memory Bound.

Cache bound means the rate at which a process progress is limited by the amount and speed of the cache available. A task that simply processes more data than fits in the cache will be cache bound.

I/O Bound would be slower than Memory Bound would be slower than Cache Bound would be slower than CPU Bound.

The solution to being I/O bound isn't necessarily to get more Memory. In some situations, the access algorithm could be designed around the I/O, Memory or Cache limitations. See Cache Oblivious Algorithms.

프로세서의 성능 평가 척도
- 명령어를 실행하는 비율(rate)이며 'MIPS rate = f x IPC'로 표현된다. 여기서 f는 프로세서 클록 주파수이며 IPC(instructions per cycle)는 사이클 당 실행되는 명령어들의 평균 수를 나타낸다.
- IPC를 높이기 위한 방법 : 명령어 수준 병렬성을 이룬다. 명령어 파이프라인, 수퍼스칼라, 그리고 멀티스래딩을 통해.

멀티스래딩(multithreading)의 정의
 - 명령어 스트림(thread)의 병렬적 실행. 멀티스래드 프로세서 내의 스래드는 소프트웨어 스래드와 같거나 다를 수 있다.
- 응용 프로그램에게 보이는 user level 스래드와 OS에게만 보이는 kernel level thread는 모두 명시적(explicit) 스래드이며 모든 상용 프로세서와 대부분의 실험용 프로세서는 명시적 스래드를 사용한다.
- 묵시적(implicit) 멀티스래딩은 하나의 순차적 프로그램으로부터 추출한 다수의 스래드를 동시해 실행하는 것을 뜻하며, 컴파일러에 의해 정적으로 또는 하드웨어에 의해 동적으로 정의된다.

명시적 멀티스래딩의 방법
- 멀티스래드 프로세서는 동시에 실행될 각 스래드를 위해 별도의 Program Counter가 제공어야 하며, 넓게 보아 네가지 주요 방법이 존재한다.

interleaved multithreading
프로세서는 한번에 두 개 혹은 그 이상의 스래드를 다루며, 각 클록 사이클마다 어느 한 스래드로부터 다른 스래드로 스위칭한다. fine-grain multithreading이라고도 한다.

blocked multithreading
스래드의 명령어들은 cache miss와 같이 latency를 유발하는 사건이 발생할 때까지 연속해서 실행되고, 사건 발생 시 다른 스래드로 스위치된다. coarse-grain multithreading이라고도 부른다.

simultaneous multithreading: SMT
명령어들이 다수의 스래드로부터 수퍼스칼라 프로세서의 실행 유닛들로 동시에 발송(issue)된다. 넓은 수퍼스칼라 명령어 발송 능력과 다수의 thread context의 결합 형태이다. intel사의 Hyperthreading은 두 개의 스래드를 지원하는 SMT이다. 

chip multiprocessing
전체 프로세서가 하나의 칩에 중복되어 들어가며, 각 프로세서는 별도의 스래드들을 처리한다. 파이프라인 설계에서 복잡도가 증가되는 것과는 상관없이 칩 상의 이용 가능한 영역이 효과적으로 사용될 수 있다는 장점이 있다. multicore(또는 chip level multiprocessing; CMP)가 여기에 속한다(?).

스칼라 프로세서의 경우
- 멀티스래딩을 지원하지 않는 단일 스래드 스칼라, interleaved multithreaded scalar, blocked multithreaded scalar가 있다.

Getting started with PTLSim : 

 http://www.ptlsim.org/Documentation/html/node17.html#SECTION04210000000000000000

PTLSim guidance : http://www.ptlsim.org/Documentation/PTLsimManual.pdf

Computer Architecture Simulator : http://en.wikipedia.org/wiki/Computer_architecture_simulator

Event-driven simulation

If events aren't guaranteed to occur at regular intervals, and we don't have a good bound on the time step (it shouldn't be so small as to make the simulation run too long, nor so large as to make the number of events unmanageable), then it's more appropriate to use an event-driven simulation. A typical example might be simulating a lineup at a bank, where customers don't arrive at regular time intervals, and may be deterred by a long lineup.

This approach uses a list of events that occur at various time, and handles them in order of increasing time. Handling an event may alter the list of later events. The simulation makes time ``jump'' to the time of the next event.

How do we stop? Again, we can stop when time reaches a certain point, or when the system reaches a certain state. Here is a generic event-driven algorithm:

1. Initialize system state
2. Initialize event list
3. While (simulation not finished)
   1. Collect statistics from current state
   2. Remove first event from list, handle it
   3. Set time to the time of this event.

How is the list of events managed? It should be ordered by increasing time (a priority heap might be efficient). We don't generate all the events in the list at the beginning (this would be analogous to knowing the entire sequence of states of the simulation at the outset). Instead we initialize the simulation with certain events, with their associated times. Certain events may be handled by scheduling later events, which are inserted at the appropriate place in the event list.

As stated above, we could stop when time reaches or exceeds a certain point, or once the system reaches a certain state (the bank is lined up for two blocks...). Sometimes we want the stopping condition itself to be randomized: we can schedule a random pseudo-event which doesn't change the state of the model, but simply stops the simulation.

참고자료 : http://stdcxx.apache.org/doc/stdlibug/11-3.html